> -----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. > > >> - 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 > >> <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 ��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
