RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Rest everything we can handle in driver once input source and output destination format receives from application. From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field for this configuration. Thanks, Vaibhav Hiremath Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is necessary if we have that kind of device. [Hiremath, Vaibhav] I am talking to Mauro, and will keep you updated on this. Thanks, Vaibhav Hiremath Thanks, Vaibhav From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field for this configuration. I get it. But S3C64XX is not that much configurable. As you see in user manual, it's a quite simple device. For now I'm still designing my driver, so I'll let you know if I face those issues in my driver. Cheers, Nate Thanks, Vaibhav Hiremath Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. Oh! sorry I made you get confused. What I'm working on is not the TV scaler of S3C64XX but scaler and rotator in camera interface. Please take a look at 20-1 camera interface This scaler/rotator feature can be used in general purpose. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is necessary if we have that kind of device. [Hiremath, Vaibhav] I am talking to Mauro, and will keep you updated on this. Thank you. I appreciate it. Nate Thanks, Vaibhav Hiremath Thanks, Vaibhav From OMAP Point of view - --- The extra configuration is coefficients, which if we don't export to user application then I think we are very close to your IP. Extra configuration required other than coeff. RSZ_YENH - which takes 4 params - Algo - Gain - Slope - Core All are part of one register so we can make use of priv field
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
-Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 6:34 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Tuesday, April 21, 2009 3:44 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Tuesday, April 21, 2009 3:16 PM To: 'Dongsoo, Nathaniel Kim' Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Hi Kim, I went through the document and below are some observations and questions I have - - If I compare it with OMAP then there is nothing application needs to configure specific to hardware. All the parameters supported through v4l2_format one with TYPE_VIDEO_OUTPUT and another with TYPE_VIDEO_CAPTURE except the parameter offset (If driver is supporting it) I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about offset parameter. Can you explain me more specifically? [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) 16.7.11 and 16.7.16. You can specify offset from the input image to start, so that you can have part of image for scaling. Oh! sorry I made you get confused. What I'm working on is not the TV scaler of S3C64XX but scaler and rotator in camera interface. Please take a look at 20-1 camera interface This scaler/rotator feature can be used in general purpose. - I wanted to understand how are you configuring offset register? How are you exporting it to user application? Again, I don't get the point. Sorry. Rest everything we can handle in driver once input source and output destination format receives from application. [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. How are you handling buffers? Are you supporting both USER_POINTER and MMAP buffers? What is the size of buffers, is that different for input and output? If yes, then how are you managing it? If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/ davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, April 18, 2009 9:24 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. [Hiremath, Vaibhav] Agreed, and you will also find implementation of driver aligned to this which I have shared with you. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss this in detail and try to get closure on it. Again I would request you to join me and mauro on IRC chat, I will be staying online tomorrow. Regards, Hans -- 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C6400X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] Sent: Monday, April 20, 2009 4:15 PM To: Hiremath, Vaibhav Cc: Hans Verkuil; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Vaibhav, This is user manual of S3C6400 (not much different from S3C6410) http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 00X_UserManual_rev1-0_2008-02_661558um.pdf That SoC is from my company but not from the same division of mine. Actually I'm doing this driver job without any request from chip delivering division. I'm doing this because this is so challenging and want better generic driver :-) Take a look at the user manual and please let me know your opinion. In my understanding scaler and some camera interface feature in S3C64XX are very similar to the features in Omap3. [Hiremath, Vaibhav] Thanks for the link, I will go though it and get back to you. Cheers, Nate On Mon, Apr 20, 2009 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: Thanks, Vaibhav Hiremath -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Dongsoo Kim Sent: Sunday, April 19, 2009 12:06 PM To: Hans Verkuil Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. [Hiremath, Vaibhav] Can you share the spec for the same; I wanted to verify the configuration part of it? What all configuration is exported to the user? But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) [Hiremath, Vaibhav] I have also implemented the driver is the same way and also working with Hans to get it reviewed. But there are some configuration like coeff., luma enhancement, etc... need to export to the user, where we need to add mechanism in V4L2 framework. Since we have one more device where we are demanding for M-to-M operation, I think it is important to go through it. Can you share some documents of your IP for better understanding. Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Monday 20 April 2009 12:31:53 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, April 18, 2009 9:24 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. [Hiremath, Vaibhav] Agreed, and you will also find implementation of driver aligned to this which I have shared with you. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). [Hiremath, Vaibhav] Hans, Can we have IRC session for this? We will discuss this in detail and try to get closure on it. Again I would request you to join me and mauro on IRC chat, I will be staying online tomorrow. No problem (assuming we don't have another major network outage as we had today at work). It would be helpful if you could mail a summary of the capabilities that are needed but are not yet in the API. Also note that I have to leave at 16:15 (UTC+2). Magnus, does the SuperH also have resizing/previewer capabilities? And if so, is there a datasheet available with detailed information? Regards, Hans -- 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Hans and Hiremath, One of my recent job is making S3C64XX camera interface driver (even though other jobs of mine are not finished yet...;-() And, what a incident! S3C64XX has also similar H/W block in camera interface. Resizer in S3C camera interface can be used in system wide like the one in Omap3. But in case of mine, I decided to make it as a TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT. I thought that is was enough. Actually I took omap video out (vout?) for reference :-) Cheers, Nate 2009. 04. 19, 오전 12:53, Hans Verkuil 작성: On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/ davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area and he may have fixed some of these issues already. Very useful, that Embedded Linux conference... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG = 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. To be honest, I don't see the need for this. I think TYPE_VIDEO_CAPTURE and TYPE_VIDEO_OUTPUT are perfectly fine. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I agree. Especially since you cannot use it as a pointer to addition information. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. The big question is how many of these capabilities are 'generic' and how many are very much hardware specific. I am leaning towards using the extended control API for this. It's a bit awkward to implement in drivers at the moment, but that should improve in the future when a lot of the control handling code will move into the new core framework. I really need to know more about the sort of features that omap/davinci offer (and preferably also for similar devices by other manufacturers). Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? I've asked Magnus Damm to take a look at this. I know he did some work in this area and he may have fixed some of these issues already. Very useful, that Embedded Linux conference... Regards, Hans -- 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? Regards, Hans -- 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Tuesday 31 March 2009 10:53:02 Hiremath, Vaibhav wrote: Thanks, Vaibhav Hiremath APPROACH 3 - -- . (Any other approach which I could not think of would be appreciated) I would prefer second approach, since this will provide standard interface to applications independent on underneath hardware. There may be many number of such configuration parameters required for different such devices, we need to work on this and come up with some standard capability fields covering most of available devices. Does anybody have some other opinions on this? Any suggestions will be helpful here, FYI: I have very little time to look at this for the next 2-3 weeks. As you know I'm working on the last pieces of the v4l2_subdev conversion for 2.6.30 that should be finished this week. After that I'm attending the Embedded Linux Conference in San Francisco. But I always thought that something like this would be just a regular video device that can do both 'output' and 'capture'. For a resizer I would expect that you set the 'output' size (the size of your source image) and the 'capture' size (the size of the resized image), then just send the frames to the device (== resizer) and get them back on the capture side. [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. I haven't had the time to look at this yet. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using priv field for custom configuration. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... These things are always hard to do since the capabilities are so hardware dependent. You either end up with a controls-like API (where you basically can enumerate the capabilities), or you go for a split API: part is for common functionality, and another part is purely device specific. This way we can make sure that, any such future devices can be adapted by this framework. Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? No, but videobuf is more Mauro's expertise. As I said, I will have very little time to really look into this until some 2-3 weeks from now :-( Regards, Hans -- 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
[RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. One thing I am not able to understand, how nobody came across such use-case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can make use of readily available V4L2 framework interface for data and control path to manage buffers. We should enhance V4L2 framework to support such devices. Proposed Required Changes - -- I am putting some high level changes required to be done for supporting such devices - - Enhancement in V4L2-buf layer for above issues - Will be directly using sub-device frame-work and have to enhance it to support such devices. - Below are the parameters we need to configure for Resizer from user application - __s32 in_hsize;/* input frame horizontal size.*/ __s32 in_vsize;/* input frame vertical size */ __s32 in_pitch;/* offset between 2 rows of input frame.*/ __s32 inptyp; /* for determining 16 bit or 8 bit data.*/ __s32 vert_starting_pixel; /* vertical starting pixel in input.*/ __s32 horz_starting_pixel; /* horizontal starting pixel in input.*/ __s32 cbilin; /* filter with luma or bi-linear interpolation.*/ __s32 pix_fmt; /* UYVY or YUYV */ __s32 out_hsize; /* output frame horizontal size. */ __s32 out_vsize; /* output frame vertical size.*/ __s32 out_pitch; /* offset between 2 rows of output frame.*/ __s32 hstph; /* for specifying horizontal starting phase.*/ __s32 vstph; /* for specifying vertical starting phase.*/ __u16 tap4filt_coeffs[32]; /* horizontal filtercoefficients.*/ __u16 tap7filt_coeffs[32]; /* vertical filter coefficients. */ struct rsz_yenh yenh_params; (Pasted from previous patches posted by Sergio) Putting one sample proposal using VIDIOC_S_FMT - APPROACH 1 - -- Either we can add this under struct v4l2_format or need to enhance stuct v4l2_crop to support such device. We can use 'VIDIOC_S_FMT' ioctl to configure the resizer parameters. From top level it will look something like - struct v4l2_buffer buf; struct
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Op 30 mrt 2009, om 16:34 heeft Hiremath, Vaibhav het volgende geschreven: Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. I extracted a patch from that branch, but I can't figure out how to actually enable the resizer on beagleboard, overo and omapzoom, since the patches to do that seem to be missing from the branches of the ISP tree. Any clue where I can get those? Also, any test apps for the new code? AIUI dmai doesn't understand the new code yet. regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Monday 30 March 2009 16:34:42 Hiremath, Vaibhav wrote: Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. One thing I am not able to understand, how nobody came across such use-case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can make use of readily available V4L2 framework interface for data and control path to manage buffers. We should enhance V4L2 framework to support such devices. Proposed Required Changes - -- I am putting some high level changes required to be done for supporting such devices - - Enhancement in V4L2-buf layer for above issues - Will be directly using sub-device frame-work and have to enhance it to support such devices. - Below are the parameters we need to configure for Resizer from user application - __s32 in_hsize;/* input frame horizontal size.*/ __s32 in_vsize;/* input frame vertical size */ __s32 in_pitch;/* offset between 2 rows of input frame.*/ __s32 inptyp; /* for determining 16 bit or 8 bit data.*/ __s32 vert_starting_pixel; /* vertical starting pixel in input.*/ __s32 horz_starting_pixel; /* horizontal starting pixel in input.*/ __s32 cbilin; /* filter with luma or bi-linear interpolation.*/ __s32 pix_fmt; /* UYVY or YUYV */ __s32 out_hsize; /* output frame horizontal size. */ __s32 out_vsize; /* output frame vertical size.*/ __s32 out_pitch; /* offset between 2 rows of output frame.*/ __s32 hstph; /* for specifying horizontal starting phase.*/ __s32 vstph; /* for specifying vertical starting phase.*/ __u16 tap4filt_coeffs[32]; /* horizontal filtercoefficients.*/ __u16 tap7filt_coeffs[32]; /* vertical filter coefficients. */ struct rsz_yenh yenh_params; (Pasted from previous patches posted by Sergio) Putting one sample proposal using VIDIOC_S_FMT - APPROACH 1 - -- Either we can add this under struct v4l2_format or need to enhance stuct v4l2_crop to support such device. We can use 'VIDIOC_S_FMT' ioctl to configure the resizer
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Aguirre Rodriguez, Sergio Alberto Sent: Monday, March 30, 2009 9:10 PM To: Hiremath, Vaibhav; linux-media@vger.kernel.org Cc: DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hi Vaibhav, Please find some comments below -Original Message- From: Hiremath, Vaibhav Sent: Monday, March 30, 2009 8:35 AM To: linux-media@vger.kernel.org Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail- thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. I'm not sure if I understood the problem right... Can you please help me clarify? So, basically the problem is that both drivers needs to associate a single buffer with 2 different DMA transfers at the same time (one from other driver, and other from ISP) Is that correct? [Hiremath, Vaibhav] No, Let's take real-time example here, say you have 128 Mb DDR available with you and you have asked linux to use only say 80Mb. And rest of the memory you are mapping to kernel from some another driver using ioremap. This is valid use-case, since most of application does this due to memory fragmentation. Now you want to use this ioremapped buffer for your capture driver as a use pointer exchange mechanism. And here it fails due to issues as I explained before. One thing I am not able to understand, how nobody came across such use- case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can
