v4l2_int_device vs v4l2_subdev?

v4l2_int_device vs v4l2_subdev?

[Gary Thomas]

Still trying to wrap my head around the OMAP/34xx camera support.
I need to use the TVP5150 sensor/controller, but the existing
driver uses v4l_subdev.  The "working" examples I've found
(from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device

Are these two totally separate beasts?
If I have an infrastructure (I assume) based on v4l2_int_device,
how do I use a v4l2_subdev device driver?  or need I move one to
the other?

... dizzy from traveling down too many twisty little passages :-(

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: v4l2_int_device vs v4l2_subdev?

[Dongsoo, Nathaniel Kim]

Hello,

On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomas<gary@mlbassoc.com> wrote:
> Still trying to wrap my head around the OMAP/34xx camera support.
> I need to use the TVP5150 sensor/controller, but the existing
> driver uses v4l_subdev.  The "working" examples I've found
> (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device
>
> Are these two totally separate beasts?
> If I have an infrastructure (I assume) based on v4l2_int_device,
> how do I use a v4l2_subdev device driver?  or need I move one to
> the other?
>

I've been through the same case (now I'm trying to use subdev
framework and writing a new device driver based on that)
As far as I understand, every v4l2 drivers are moving on subdev
framework. But in user space there is nothing changed having access to
device and control them.
As you know, subdev and int-device is all about how to bind
interface(or host?) and device and make them communicated each other.
But using subdev device driver with int-device supporting interface
(or host) device driver? it won't make any communication.
So if you are running out of time with your project, you'd better use
old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if
you have enough time and wanna be challenging, try to convert
in-device based omap3 camera interface driver to subdev supporting
one.
Cheers,

Nate


> ... dizzy from traveling down too many twisty little passages :-(
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> 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@gmail.com
          dongsoo45.kim@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l2_int_device vs v4l2_subdev?

[Hans Verkuil]

On Friday 26 June 2009 07:27:15 Dongsoo, Nathaniel Kim wrote:
> Hello,
> 
> On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomas<gary@mlbassoc.com> wrote:
> > Still trying to wrap my head around the OMAP/34xx camera support.
> > I need to use the TVP5150 sensor/controller, but the existing
> > driver uses v4l_subdev.  The "working" examples I've found
> > (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device
> >
> > Are these two totally separate beasts?
> > If I have an infrastructure (I assume) based on v4l2_int_device,
> > how do I use a v4l2_subdev device driver?  or need I move one to
> > the other?
> >
> 
> I've been through the same case (now I'm trying to use subdev
> framework and writing a new device driver based on that)
> As far as I understand, every v4l2 drivers are moving on subdev
> framework.

That's right. There were three different incompatible interfaces between
the host and an i2c device. This made it impossible to reuse e.g. a sensor
driver based on v4l2-int-device for omap in a USB webcam based around
the old i2c-ioctl interface. The v4l2_subdev interface was created that
will replace all these other interfaces. We will not accept new
non-v4l2-subdev drivers in the kernel, and we are working hard to convert
the last remaining non-v4l2-subdev drivers as soon as possible.

> But in user space there is nothing changed having access to 
> device and control them.
> As you know, subdev and int-device is all about how to bind
> interface(or host?) and device and make them communicated each other.
> But using subdev device driver with int-device supporting interface
> (or host) device driver? it won't make any communication.
> So if you are running out of time with your project, you'd better use
> old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if
> you have enough time and wanna be challenging, try to convert
> in-device based omap3 camera interface driver to subdev supporting
> one.

Someone's got to do this. v4l2_subdev is the future and it has many
advantages over the older interfaces. The ability to be able to use the
same i2c driver in anything from USB webcams to PCI capture cards to
omap/davinci embedded platforms is very powerful.

Regards,

	Hans

> Cheers,
> 
> Nate
> 
> 
> > ... dizzy from traveling down too many twisty little passages :-(
> >
> > --
> > ------------------------------------------------------------
> > Gary Thomas                 |  Consulting for the
> > MLB Associates              |    Embedded world
> > ------------------------------------------------------------
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
> 



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: v4l2_int_device vs v4l2_subdev?

[Aguirre Rodriguez, Sergio Alberto]

> > But in user space there is nothing changed having access to
> > device and control them.
> > As you know, subdev and int-device is all about how to bind
> > interface(or host?) and device and make them communicated each other.
> > But using subdev device driver with int-device supporting interface
> > (or host) device driver? it won't make any communication.
> > So if you are running out of time with your project, you'd better use
> > old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if
> > you have enough time and wanna be challenging, try to convert
> > in-device based omap3 camera interface driver to subdev supporting
> > one.
> 
> Someone's got to do this. v4l2_subdev is the future and it has many
> advantages over the older interfaces. The ability to be able to use the
> same i2c driver in anything from USB webcams to PCI capture cards to
> omap/davinci embedded platforms is very powerful.

Hi,

We have already this framework migration planned, but we haven't been
able to do it, because we are still solving stability issues on the driver.

I beg for your patience, and i hope i can get my hands on this pretty soon.

I'll be updating my tree when i have something.

Regards,
Sergio

Re: v4l2_int_device vs v4l2_subdev?

[Hans Verkuil]

On Friday 26 June 2009 16:43:52 Aguirre Rodriguez, Sergio Alberto wrote:
> > > But in user space there is nothing changed having access to
> > > device and control them.
> > > As you know, subdev and int-device is all about how to bind
> > > interface(or host?) and device and make them communicated each other.
> > > But using subdev device driver with int-device supporting interface
> > > (or host) device driver? it won't make any communication.
> > > So if you are running out of time with your project, you'd better use
> > > old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if
> > > you have enough time and wanna be challenging, try to convert
> > > in-device based omap3 camera interface driver to subdev supporting
> > > one.
> > 
> > Someone's got to do this. v4l2_subdev is the future and it has many
> > advantages over the older interfaces. The ability to be able to use the
> > same i2c driver in anything from USB webcams to PCI capture cards to
> > omap/davinci embedded platforms is very powerful.
> 
> Hi,
> 
> We have already this framework migration planned, but we haven't been
> able to do it, because we are still solving stability issues on the driver.
> 
> I beg for your patience, and i hope i can get my hands on this pretty soon.
> 
> I'll be updating my tree when i have something.

Sorry, I was a bit harsh there. It was not aimed at you, Sergio, but at others
who read this. I just want to make sure that everyone is aware of this new
framework and how important it is to migrate to this framework.

Moving to a new framework can be a very time consuming process, but I think
it is very important to try and get this finished as soon as possible. With
the inclusion of the omap and davinci drivers in the kernel I'm sure a lot
of new sensor and video drivers will start popping up. And if they are
written as subdev drivers from the start, then that will make inclusion in
the kernel much easier. Since sensors especially are also used in combination
with other SoCs and webcams it will be very useful indeed to have fully
reusable sensor drivers.

It's an very active period for the v4l-dvb subsystem with a lot of new
drivers and new functionality so any design decisions taken will be with
us for a long time. The extra time spent now on moving to v4l2_subdev and
thinking on how to design new APIs for new functionality is well worth it.

I consider this a critical time for the v4l subsystem in particular: once
all drivers use v4l2_subdev we will have a very powerful foundation to build
on.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom