Re: v4l2_int_device vs v4l2_subdev?

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


Re: v4l2_int_device vs v4l2_subdev?

2009-06-26 Thread 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 Thomasg...@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 majord...@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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: v4l2_int_device vs v4l2_subdev?

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


v4l2_int_device vs v4l2_subdev?

2009-06-25 Thread 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

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: v4l2_int_device vs v4l2_subdev?

2009-06-25 Thread Dongsoo, Nathaniel Kim
Hello,

On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomasg...@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 majord...@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 RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html