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