RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux