Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote: >> -----Original Message----- >> From: Dongsoo, Nathaniel Kim [mailto:dongsoo.kim@xxxxxxxxx] >> Sent: Tuesday, April 21, 2009 3:44 PM >> To: Hiremath, Vaibhav >> Cc: Hans Verkuil; linux-media@xxxxxxxxxxxxxxx; Aguirre Rodriguez, >> Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> omap@xxxxxxxxxxxxxxx; 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 <hvaibhav@xxxxxx> >> wrote: >> > >> >> -----Original Message----- >> >> From: Hiremath, Vaibhav >> >> Sent: Tuesday, April 21, 2009 3:16 PM >> >> To: 'Dongsoo, Nathaniel Kim' >> >> Cc: Hans Verkuil; linux-media@xxxxxxxxxxxxxxx; Aguirre Rodriguez, >> >> Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> >> omap@xxxxxxxxxxxxxxx; 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.kim@xxxxxxxxx] >> >> > Sent: Monday, April 20, 2009 4:15 PM >> >> > To: Hiremath, Vaibhav >> >> > Cc: Hans Verkuil; linux-media@xxxxxxxxxxxxxxx; Aguirre >> Rodriguez, >> >> > Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> >> > omap@xxxxxxxxxxxxxxx; 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 >> 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 >> >> <hvaibhav@xxxxxx> >> >> > wrote: >> >> > > >> >> > > >> >> > > Thanks, >> >> > > Vaibhav Hiremath >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media- >> >> > >> owner@xxxxxxxxxxxxxxx] On Behalf Of Dongsoo Kim >> >> > >> Sent: Sunday, April 19, 2009 12:06 PM >> >> > >> To: Hans Verkuil >> >> > >> Cc: Hiremath, Vaibhav; linux-media@xxxxxxxxxxxxxxx; Aguirre >> >> > >> Rodriguez, Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); >> >> > linux- >> >> > >> omap@xxxxxxxxxxxxxxx; 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 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 R&D Centre >> >> > >> Samsung Electronics CO., LTD. >> >> > >> e-mail : dongsoo.kim@xxxxxxxxx >> >> > >> dongsoo45.kim@xxxxxxxxxxx >> >> > >> >> >> > >> >> >> > >> >> >> > >> -- >> >> > >> To unsubscribe from this list: send the line "unsubscribe >> >> linux- >> >> > >> media" in >> >> > >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> > >> More majordomo info at http://vger.kernel.org/majordomo- >> >> > info.html >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> > -- >> >> > ======================================================== >> >> > DongSoo, Nathaniel Kim >> >> > Engineer >> >> > Mobile S/W Platform Lab. >> >> > Digital Media & Communications R&D Centre >> >> > Samsung Electronics CO., LTD. >> >> > e-mail : dongsoo.kim@xxxxxxxxx >> >> > dongsoo45.kim@xxxxxxxxxxx >> >> > ======================================================== >> > >> > >> >> >> >> -- >> = >> DongSoo, Nathaniel Kim >> Engineer >> Mobile S/W Platform Lab. >> Digital Media & Communications R&D Centre >> Samsung Electronics CO., LTD. >> e-mail : dongsoo.kim@xxxxxxxxx >> dongsoo45.kim@xxxxxxxxxxx > > -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo.kim@xxxxxxxxx dongsoo45.kim@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
