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

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

 



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?


>>       - 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.

>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux