Conversion of vino driver for SGI to not use the legacy decoder API

Conversion of vino driver for SGI to not use the legacy decoder API

[Mauro Carvalho Chehab]

After the conversion of Zoran driver to V4L2, now almost all drivers are using
the new API. However, there are is one remaining driver using the
video_decoder.h API (based on V4L1 API) for message exchange between the bridge
driver and the i2c sensor: the vino driver.

This driver adds support for the Indy webcam and for a capture hardware on SGI.
Does someone have those hardware? If so, are you interested on helping to
convert those drivers to fully use V4L2 API?

The SGI driver is located at:
	drivers/media/video/vino.c

Due to vino, those two drivers are also using the old API:
	drivers/media/video/indycam.c
	drivers/media/video/saa7191.c

It shouldn't be hard to convert those files to use the proper APIs, but AFAIK
none of the current active developers has any hardware for testing it.

Cheers,
Mauro

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Hans Verkuil]

On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote:
> After the conversion of Zoran driver to V4L2, now almost all drivers are
> using the new API. However, there are is one remaining driver using the
> video_decoder.h API (based on V4L1 API) for message exchange between the
> bridge driver and the i2c sensor: the vino driver.
>
> This driver adds support for the Indy webcam and for a capture hardware
> on SGI. Does someone have those hardware? If so, are you interested on
> helping to convert those drivers to fully use V4L2 API?
>
> The SGI driver is located at:
> 	drivers/media/video/vino.c
>
> Due to vino, those two drivers are also using the old API:
> 	drivers/media/video/indycam.c
> 	drivers/media/video/saa7191.c
>
> It shouldn't be hard to convert those files to use the proper APIs, but
> AFAIK none of the current active developers has any hardware for testing
> it.

The conversion has already been done in my v4l-dvb-vino tree. I'm trying to 
convince the original vino author to boot up his Indy and test it, but he 
is not very interested in doing that. I'll ask him a few more times, but we 
may have to just merge my code untested. Or perhaps just drop it.

Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi 
code could be dropped which is only used by vino. How important is that to 
you? Perhaps we are flogging a dead horse here and we should just let this 
driver die.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Jean Delvare]

Hi Hans,

On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote:
> On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote:
> > After the conversion of Zoran driver to V4L2, now almost all drivers are
> > using the new API. However, there are is one remaining driver using the
> > video_decoder.h API (based on V4L1 API) for message exchange between the
> > bridge driver and the i2c sensor: the vino driver.
> >
> > This driver adds support for the Indy webcam and for a capture hardware
> > on SGI. Does someone have those hardware? If so, are you interested on
> > helping to convert those drivers to fully use V4L2 API?
> >
> > The SGI driver is located at:
> > 	drivers/media/video/vino.c
> >
> > Due to vino, those two drivers are also using the old API:
> > 	drivers/media/video/indycam.c
> > 	drivers/media/video/saa7191.c
> >
> > It shouldn't be hard to convert those files to use the proper APIs, but
> > AFAIK none of the current active developers has any hardware for testing
> > it.
> 
> The conversion has already been done in my v4l-dvb-vino tree. I'm trying to 
> convince the original vino author to boot up his Indy and test it, but he 
> is not very interested in doing that. I'll ask him a few more times, but we 
> may have to just merge my code untested. Or perhaps just drop it.
> 
> Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi 
> code could be dropped which is only used by vino. How important is that to 
> you? Perhaps we are flogging a dead horse here and we should just let this 
> driver die.

My rant was based on the fact that i2c-algo-sgi is totally SGI-specific
while i2c-algo-* modules are supposed to be generic abstractions that
can be reused by a variety of hardware. So i2c-algo-sgi should really be
merged into drivers/media/video/vino.c. But as it takes a SGI system to
build-test such a change, and I don't have one, I am reluctant to do
it. If we can find a tester for your V4L2 conversion then maybe the
same tester will be able to test my own changes.

But i2c-algo-sgi isn't a big problem per se, it doesn't block further
evolutions or anything like that, so if we can't find a tester and it
has to stay for a few more years, this really isn't a problem for me.

-- 
Jean Delvare

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Mauro Carvalho Chehab]

On Fri, 27 Feb 2009 10:09:47 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> Hi Hans,
> 
> On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote:
> > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote:
> > > After the conversion of Zoran driver to V4L2, now almost all drivers are
> > > using the new API. However, there are is one remaining driver using the
> > > video_decoder.h API (based on V4L1 API) for message exchange between the
> > > bridge driver and the i2c sensor: the vino driver.
> > >
> > > This driver adds support for the Indy webcam and for a capture hardware
> > > on SGI. Does someone have those hardware? If so, are you interested on
> > > helping to convert those drivers to fully use V4L2 API?
> > >
> > > The SGI driver is located at:
> > > 	drivers/media/video/vino.c
> > >
> > > Due to vino, those two drivers are also using the old API:
> > > 	drivers/media/video/indycam.c
> > > 	drivers/media/video/saa7191.c
> > >
> > > It shouldn't be hard to convert those files to use the proper APIs, but
> > > AFAIK none of the current active developers has any hardware for testing
> > > it.
> > 
> > The conversion has already been done in my v4l-dvb-vino tree. 

Great! Do you have any other tree converting drivers from V4L1 to V4L2 API?
Btw, we should update the dependencies for the converted drivers. They are
still dependent of V4L1:

config VIDEO_BT819
        tristate "BT819A VideoStream decoder"
        depends on VIDEO_V4L1 && I2C

I'll do such update probably later today. I want to have an overall picture on
what's still left.

> > I'm trying to 
> > convince the original vino author to boot up his Indy and test it, but he 
> > is not very interested in doing that. I'll ask him a few more times, but we 
> > may have to just merge my code untested. Or perhaps just drop it.

Well, let's merge the code. Maybe someone at the ML could have an Indy and can test it.

I think that the risk of breaking vino is not big, since this conversion is
more like a variable renaming. Also, after applying those changes at
linux-next, more people can test its code. Maybe we can add some printk's
asking for testers to contact us at LMML.

I would love to finally remove another V4L1 header (video_decoder.h).

> > Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi 
> > code could be dropped which is only used by vino. How important is that to 
> > you? Perhaps we are flogging a dead horse here and we should just let this 
> > driver die.
> 
> My rant was based on the fact that i2c-algo-sgi is totally SGI-specific
> while i2c-algo-* modules are supposed to be generic abstractions that
> can be reused by a variety of hardware. So i2c-algo-sgi should really be
> merged into drivers/media/video/vino.c. But as it takes a SGI system to
> build-test such a change, and I don't have one, I am reluctant to do
> it. If we can find a tester for your V4L2 conversion then maybe the
> same tester will be able to test my own changes.
> 
> But i2c-algo-sgi isn't a big problem per se, it doesn't block further
> evolutions or anything like that, so if we can't find a tester and it
> has to stay for a few more years, this really isn't a problem for me.

If the merger of i2c-algo-sgi is as not something complex, then we can try to
merge and apply at vino. Otherwise, we can just keep as-is.

PS.: probably you haven't noticed, but tea575x-tuner.c is still V4L1 (one of
your patches changed the header improperly, breaking sound build). 

Douglas,

As you've done several radio conversions to V4L2 API, maybe you can also handle
this one.

Cheers,
Mauro

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Hans Verkuil]

On Friday 27 February 2009 12:22:16 Mauro Carvalho Chehab wrote:
> On Fri, 27 Feb 2009 10:09:47 +0100
>
> Jean Delvare <khali@linux-fr.org> wrote:
> > Hi Hans,
> >
> > On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote:
> > > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote:
> > > > After the conversion of Zoran driver to V4L2, now almost all
> > > > drivers are using the new API. However, there are is one remaining
> > > > driver using the video_decoder.h API (based on V4L1 API) for
> > > > message exchange between the bridge driver and the i2c sensor: the
> > > > vino driver.
> > > >
> > > > This driver adds support for the Indy webcam and for a capture
> > > > hardware on SGI. Does someone have those hardware? If so, are you
> > > > interested on helping to convert those drivers to fully use V4L2
> > > > API?
> > > >
> > > > The SGI driver is located at:
> > > > 	drivers/media/video/vino.c
> > > >
> > > > Due to vino, those two drivers are also using the old API:
> > > > 	drivers/media/video/indycam.c
> > > > 	drivers/media/video/saa7191.c
> > > >
> > > > It shouldn't be hard to convert those files to use the proper APIs,
> > > > but AFAIK none of the current active developers has any hardware
> > > > for testing it.
> > >
> > > The conversion has already been done in my v4l-dvb-vino tree.
>
> Great! Do you have any other tree converting drivers from V4L1 to V4L2
> API? Btw, we should update the dependencies for the converted drivers.
> They are still dependent of V4L1:

Oops, forgot about those.

> config VIDEO_BT819
>         tristate "BT819A VideoStream decoder"
>         depends on VIDEO_V4L1 && I2C
>
> I'll do such update probably later today. I want to have an overall
> picture on what's still left.

I'm keeping a document with the state of all the drivers here:

http://www.xs4all.nl/%7Ehverkuil/drivers.txt

Basically it tells me which drivers are v4l1/2, use video_ioctl2, use 
v4l2_device and which use v4l2_subdev (this column is empty when the driver 
doesn't use modules at all). The final column tells me who can test this 
hardware.

At the bottom is a similar list of i2c modules.

I have also converted the cafe_ccic driver and I'm waiting for feedback from 
Jonathan Corbet whether it works or not.

The following drivers haven't been converted yet to v4l2_device/subdev:

em28xx (Douglas Landgraf said he'd tackle that one), pvrusb2 (Mike Isely is 
doing that one), cx88 (unassigned), bttv (I want to look at that one), 
cx23885 (also for me), and w9968cf. The last one is much more difficult 
since it is v4l1. I do have hardware to test this, but no experience 
porting from v4l1 to v4l2 or with gspca (the alternative conversion path 
that I can take). In all honesty, I was planning to just do a 
quick-and-dirty conversion to v4l2_subdev, while keeping the v4l1 API. I 
doubt I will have time to do anything more. It allows Jean to make his i2c 
cleanups and we can do a proper conversion to v4l2 later.

My status document also contains a list of the remaining v4l1 drivers:

arv, bw-qcam, c-qcam, cpia_pp: these four are ancient and we should consider 
dropping these altogether. The first seems to be tied to very specific 
hardware (we should contact the author first before making any decision on 
that one), the others are for parallel port webcams.

cpia_usb: ancient, but USB and I got my hands on one, so that might be 
interesting to see if it can be converted.

ov511: I got hardware for that one as well

pms: Amazingly, I got hardware for this one as well. Totally useless ISA 
video capture card, but it actually works and as a fun project I want to 
upgrade that one.

se401: I don't believe I have hardware for this one (I'm scouring ebay these 
days for old stuff, but I don't think I found hardware for this driver).

stradis: can't find any hardware at all. We might want to contact the author 
first, though, since these are (semi-?)professional devices.

stv680: got hardware for this

usbvideo: ditto

w9966: can't find any hardware for this one.

w9968cf: have hardware as described above.

Actually, if anyone else is interested in converting some of these drivers 
to v4l2 or gspca, I'd be happy to send him the hardware. It's too much work 
for one person, really.

The reason for me collecting all this information and hardware is that I 
think that for 2.6.31 we should set our goal to abolish these last v4l1 
drivers. In parallel to that we should convert the other drivers to 
v4l2_device and video_ioctl2 which gives a great foundation for the future.

> > > I'm trying to
> > > convince the original vino author to boot up his Indy and test it,
> > > but he is not very interested in doing that. I'll ask him a few more
> > > times, but we may have to just merge my code untested. Or perhaps
> > > just drop it.
>
> Well, let's merge the code. Maybe someone at the ML could have an Indy
> and can test it.
>
> I think that the risk of breaking vino is not big, since this conversion
> is more like a variable renaming. Also, after applying those changes at
> linux-next, more people can test its code. Maybe we can add some printk's
> asking for testers to contact us at LMML.
>
> I would love to finally remove another V4L1 header (video_decoder.h).

OK, I'll send the pull request.

> > > Jean, I remember you mentioning that you wouldn't mind if the
> > > i2c-algo-sgi code could be dropped which is only used by vino. How
> > > important is that to you? Perhaps we are flogging a dead horse here
> > > and we should just let this driver die.
> >
> > My rant was based on the fact that i2c-algo-sgi is totally SGI-specific
> > while i2c-algo-* modules are supposed to be generic abstractions that
> > can be reused by a variety of hardware. So i2c-algo-sgi should really
> > be merged into drivers/media/video/vino.c. But as it takes a SGI system
> > to build-test such a change, and I don't have one, I am reluctant to do
> > it. If we can find a tester for your V4L2 conversion then maybe the
> > same tester will be able to test my own changes.
> >
> > But i2c-algo-sgi isn't a big problem per se, it doesn't block further
> > evolutions or anything like that, so if we can't find a tester and it
> > has to stay for a few more years, this really isn't a problem for me.
>
> If the merger of i2c-algo-sgi is as not something complex, then we can
> try to merge and apply at vino. Otherwise, we can just keep as-is.
>
> PS.: probably you haven't noticed, but tea575x-tuner.c is still V4L1 (one
> of your patches changed the header improperly, breaking sound build).

Ah, missed that one. Sorry for the breakage. Added it to my status list. 
Should be trivial to convert to v4l2 looking at the code.

Regards,

	Hans

> Douglas,
>
> As you've done several radio conversions to V4L2 API, maybe you can also
> handle this one.
>
> Cheers,
> Mauro



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Hans Verkuil]

On Friday 27 February 2009 12:53:28 Hans Verkuil wrote:
> On Friday 27 February 2009 12:22:16 Mauro Carvalho Chehab wrote:
> > Well, let's merge the code. Maybe someone at the ML could have an Indy
> > and can test it.
> >
> > I think that the risk of breaking vino is not big, since this
> > conversion is more like a variable renaming. Also, after applying those
> > changes at linux-next, more people can test its code. Maybe we can add
> > some printk's asking for testers to contact us at LMML.
> >
> > I would love to finally remove another V4L1 header (video_decoder.h).
>
> OK, I'll send the pull request.

This will be delayed until early next week. I think I may have forgotten to 
push some final changes to my vino tree but I won't have access to that PC 
until Sunday.

> > > > Jean, I remember you mentioning that you wouldn't mind if the
> > > > i2c-algo-sgi code could be dropped which is only used by vino. How
> > > > important is that to you? Perhaps we are flogging a dead horse here
> > > > and we should just let this driver die.
> > >
> > > My rant was based on the fact that i2c-algo-sgi is totally
> > > SGI-specific while i2c-algo-* modules are supposed to be generic
> > > abstractions that can be reused by a variety of hardware. So
> > > i2c-algo-sgi should really be merged into drivers/media/video/vino.c.
> > > But as it takes a SGI system to build-test such a change, and I don't
> > > have one, I am reluctant to do it. If we can find a tester for your
> > > V4L2 conversion then maybe the same tester will be able to test my
> > > own changes.
> > >
> > > But i2c-algo-sgi isn't a big problem per se, it doesn't block further
> > > evolutions or anything like that, so if we can't find a tester and it
> > > has to stay for a few more years, this really isn't a problem for me.
> >
> > If the merger of i2c-algo-sgi is as not something complex, then we can
> > try to merge and apply at vino. Otherwise, we can just keep as-is.

Jean, if you are interested in doing this, then use my v4l-dvb-vino2 tree as 
the starting point. It would be nice to get it all done in one go.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Jean Delvare]

Hi Hans,

On Fri, 27 Feb 2009 13:12:10 +0100, Hans Verkuil wrote:
> Jean, if you are interested in doing this, then use my v4l-dvb-vino2 tree as 
> the starting point. It would be nice to get it all done in one go.

Here you go. The patch below adds the i2c-algo-sgi code to vino. Then
we can delete i2c-algo-sgi altogether, but as this driver isn't part of
the v4l-dvb tree, this has to go through another route (likely my i2c
tree.)

==========

Merge i2c-algo-sgi into its only user, vino. This is a very simple
copy-and-paste approach, although a number of further cleanups are
possible.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
Note: totally untested!

 linux/drivers/media/video/Kconfig |    1 
 linux/drivers/media/video/vino.c  |  169 ++++++++++++++++++++++++++++++++++---
 2 files changed, 156 insertions(+), 14 deletions(-)

--- v4l-dvb-vino2.orig/linux/drivers/media/video/Kconfig	2009-02-27 13:21:39.000000000 +0100
+++ v4l-dvb-vino2/linux/drivers/media/video/Kconfig	2009-02-27 13:46:55.000000000 +0100
@@ -582,7 +582,6 @@ config VIDEO_SAA5249
 config VIDEO_VINO
 	tristate "SGI Vino Video For Linux (EXPERIMENTAL)"
 	depends on I2C && SGI_IP22 && EXPERIMENTAL && VIDEO_V4L2
-	select I2C_ALGO_SGI
 	select VIDEO_SAA7191 if VIDEO_HELPER_CHIPS_AUTO
 	help
 	  Say Y here to build in support for the Vino video input system found
--- v4l-dvb-vino2.orig/linux/drivers/media/video/vino.c	2009-02-27 13:21:40.000000000 +0100
+++ v4l-dvb-vino2/linux/drivers/media/video/vino.c	2009-02-27 14:56:52.000000000 +0100
@@ -33,7 +33,6 @@
 #include <linux/kmod.h>
 
 #include <linux/i2c.h>
-#include <linux/i2c-algo-sgi.h>
 
 #include <linux/videodev2.h>
 #include <media/v4l2-device.h>
@@ -141,6 +140,20 @@ MODULE_LICENSE("GPL");
 
 #define VINO_DATA_NORM_COUNT		4
 
+/* I2C controller flags */
+#define SGI_I2C_FORCE_IDLE		(0 << 0)
+#define SGI_I2C_NOT_IDLE		(1 << 0)
+#define SGI_I2C_WRITE			(0 << 1)
+#define SGI_I2C_READ			(1 << 1)
+#define SGI_I2C_RELEASE_BUS		(0 << 2)
+#define SGI_I2C_HOLD_BUS		(1 << 2)
+#define SGI_I2C_XFER_DONE		(0 << 4)
+#define SGI_I2C_XFER_BUSY		(1 << 4)
+#define SGI_I2C_ACK			(0 << 5)
+#define SGI_I2C_NACK			(1 << 5)
+#define SGI_I2C_BUS_OK			(0 << 7)
+#define SGI_I2C_BUS_ERR			(1 << 7)
+
 /* Internal data structure definitions */
 
 struct vino_input {
@@ -640,6 +653,17 @@ struct v4l2_queryctrl vino_saa7191_v4l2_
 
 /* VINO I2C bus functions */
 
+struct i2c_algo_sgi_data {
+	void *data;	/* private data for lowlevel routines */
+	unsigned (*getctrl)(void *data);
+	void (*setctrl)(void *data, unsigned val);
+	unsigned (*rdata)(void *data);
+	void (*wdata)(void *data, unsigned val);
+
+	int xfer_timeout;
+	int ack_timeout;
+};
+
 unsigned i2c_vino_getctrl(void *data)
 {
 	return vino->i2c_control;
@@ -670,6 +694,134 @@ static struct i2c_algo_sgi_data i2c_sgi_
 	.ack_timeout  = 1000,
 };
 
+static int wait_xfer_done(struct i2c_algo_sgi_data *adap)
+{
+	int i;
+
+	for (i = 0; i < adap->xfer_timeout; i++) {
+		if ((adap->getctrl(adap->data) & SGI_I2C_XFER_BUSY) == 0)
+			return 0;
+		udelay(1);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int wait_ack(struct i2c_algo_sgi_data *adap)
+{
+	int i;
+
+	if (wait_xfer_done(adap))
+		return -ETIMEDOUT;
+	for (i = 0; i < adap->ack_timeout; i++) {
+		if ((adap->getctrl(adap->data) & SGI_I2C_NACK) == 0)
+			return 0;
+		udelay(1);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static int force_idle(struct i2c_algo_sgi_data *adap)
+{
+	int i;
+
+	adap->setctrl(adap->data, SGI_I2C_FORCE_IDLE);
+	for (i = 0; i < adap->xfer_timeout; i++) {
+		if ((adap->getctrl(adap->data) & SGI_I2C_NOT_IDLE) == 0)
+			goto out;
+		udelay(1);
+	}
+	return -ETIMEDOUT;
+out:
+	if (adap->getctrl(adap->data) & SGI_I2C_BUS_ERR)
+		return -EIO;
+	return 0;
+}
+
+static int do_address(struct i2c_algo_sgi_data *adap, unsigned int addr,
+		      int rd)
+{
+	if (rd)
+		adap->setctrl(adap->data, SGI_I2C_NOT_IDLE);
+	/* Check if bus is idle, eventually force it to do so */
+	if (adap->getctrl(adap->data) & SGI_I2C_NOT_IDLE)
+		if (force_idle(adap))
+			return -EIO;
+	/* Write out the i2c chip address and specify operation */
+	adap->setctrl(adap->data,
+		      SGI_I2C_HOLD_BUS | SGI_I2C_WRITE | SGI_I2C_NOT_IDLE);
+	if (rd)
+		addr |= 1;
+	adap->wdata(adap->data, addr);
+	if (wait_ack(adap))
+		return -EIO;
+	return 0;
+}
+
+static int i2c_read(struct i2c_algo_sgi_data *adap, unsigned char *buf,
+		    unsigned int len)
+{
+	int i;
+
+	adap->setctrl(adap->data,
+		      SGI_I2C_HOLD_BUS | SGI_I2C_READ | SGI_I2C_NOT_IDLE);
+	for (i = 0; i < len; i++) {
+		if (wait_xfer_done(adap))
+			return -EIO;
+		buf[i] = adap->rdata(adap->data);
+	}
+	adap->setctrl(adap->data, SGI_I2C_RELEASE_BUS | SGI_I2C_FORCE_IDLE);
+
+	return 0;
+
+}
+
+static int i2c_write(struct i2c_algo_sgi_data *adap, unsigned char *buf,
+		     unsigned int len)
+{
+	int i;
+
+	/* We are already in write state */
+	for (i = 0; i < len; i++) {
+		adap->wdata(adap->data, buf[i]);
+		if (wait_ack(adap))
+			return -EIO;
+	}
+	return 0;
+}
+
+static int sgi_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs,
+		    int num)
+{
+	struct i2c_algo_sgi_data *adap = i2c_adap->algo_data;
+	struct i2c_msg *p;
+	int i, err = 0;
+
+	for (i = 0; !err && i < num; i++) {
+		p = &msgs[i];
+		err = do_address(adap, p->addr, p->flags & I2C_M_RD);
+		if (err || !p->len)
+			continue;
+		if (p->flags & I2C_M_RD)
+			err = i2c_read(adap, p->buf, p->len);
+		else
+			err = i2c_write(adap, p->buf, p->len);
+	}
+
+	return (err < 0) ? err : i;
+}
+
+static u32 sgi_func(struct i2c_adapter *adap)
+{
+	return I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm sgi_algo = {
+	.master_xfer	= sgi_xfer,
+	.functionality	= sgi_func,
+};
+
 /*
  * There are two possible clients on VINO I2C bus, so we limit usage only
  * to them.
@@ -727,21 +879,12 @@ static struct i2c_adapter vino_i2c_adapt
 {
 	.name			= "VINO I2C bus",
 	.id			= I2C_HW_SGI_VINO,
+	.algo			= &sgi_algo,
 	.algo_data		= &i2c_sgi_vino_data,
 	.client_register	= &i2c_vino_client_reg,
 	.client_unregister	= &i2c_vino_client_unreg,
 };
 
-static int vino_i2c_add_bus(void)
-{
-	return i2c_sgi_add_bus(&vino_i2c_adapter);
-}
-
-static int vino_i2c_del_bus(void)
-{
-	return i2c_del_adapter(&vino_i2c_adapter);
-}
-
 static int i2c_camera_command(unsigned int cmd, void *arg)
 {
 	return vino_drvdata->camera.driver->
@@ -4079,7 +4222,7 @@ static void vino_module_cleanup(int stag
 		video_unregister_device(vino_drvdata->a.vdev);
 		vino_drvdata->a.vdev = NULL;
 	case 9:
-		vino_i2c_del_bus();
+		i2c_del_adapter(&vino_i2c_adapter);
 	case 8:
 		free_irq(SGI_VINO_IRQ, NULL);
 	case 7:
@@ -4301,7 +4444,7 @@ static int __init vino_module_init(void)
 	}
 	vino_init_stage++;
 
-	ret = vino_i2c_add_bus();
+	ret = i2c_add_adapter(&vino_i2c_adapter);
 	if (ret) {
 		printk(KERN_ERR "VINO I2C bus registration failed\n");
 		vino_module_cleanup(vino_init_stage);

-- 
Jean Delvare

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Douglas Schilling Landgraf]

Hello there,

On Fri, 27 Feb 2009 08:22:16 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> On Fri, 27 Feb 2009 10:09:47 +0100
> Jean Delvare <khali@linux-fr.org> wrote:
> 
> > Hi Hans,
> > 
> > On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote:
> > > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote:
> > > > After the conversion of Zoran driver to V4L2, now almost all
> > > > drivers are using the new API. However, there are is one
> > > > remaining driver using the video_decoder.h API (based on V4L1
> > > > API) for message exchange between the bridge driver and the i2c
> > > > sensor: the vino driver.
> > > >
> > > > This driver adds support for the Indy webcam and for a capture
> > > > hardware on SGI. Does someone have those hardware? If so, are
> > > > you interested on helping to convert those drivers to fully use
> > > > V4L2 API?
> > > >
> > > > The SGI driver is located at:
> > > > 	drivers/media/video/vino.c
> > > >
> > > > Due to vino, those two drivers are also using the old API:
> > > > 	drivers/media/video/indycam.c
> > > > 	drivers/media/video/saa7191.c
> > > >
> > > > It shouldn't be hard to convert those files to use the proper
> > > > APIs, but AFAIK none of the current active developers has any
> > > > hardware for testing it.
> > > 
> > > The conversion has already been done in my v4l-dvb-vino tree. 
> 
> Great! Do you have any other tree converting drivers from V4L1 to
> V4L2 API? Btw, we should update the dependencies for the converted
> drivers. They are still dependent of V4L1:
> 
> config VIDEO_BT819
>         tristate "BT819A VideoStream decoder"
>         depends on VIDEO_V4L1 && I2C
> 
> I'll do such update probably later today. I want to have an overall
> picture on what's still left.
> 
> > > I'm trying to 
> > > convince the original vino author to boot up his Indy and test
> > > it, but he is not very interested in doing that. I'll ask him a
> > > few more times, but we may have to just merge my code untested.
> > > Or perhaps just drop it.
> 
> Well, let's merge the code. Maybe someone at the ML could have an
> Indy and can test it.
> 
> I think that the risk of breaking vino is not big, since this
> conversion is more like a variable renaming. Also, after applying
> those changes at linux-next, more people can test its code. Maybe we
> can add some printk's asking for testers to contact us at LMML.
> 
> I would love to finally remove another V4L1 header (video_decoder.h).
> 
> > > Jean, I remember you mentioning that you wouldn't mind if the
> > > i2c-algo-sgi code could be dropped which is only used by vino.
> > > How important is that to you? Perhaps we are flogging a dead
> > > horse here and we should just let this driver die.
> > 
> > My rant was based on the fact that i2c-algo-sgi is totally
> > SGI-specific while i2c-algo-* modules are supposed to be generic
> > abstractions that can be reused by a variety of hardware. So
> > i2c-algo-sgi should really be merged into
> > drivers/media/video/vino.c. But as it takes a SGI system to
> > build-test such a change, and I don't have one, I am reluctant to
> > do it. If we can find a tester for your V4L2 conversion then maybe
> > the same tester will be able to test my own changes.
> > 
> > But i2c-algo-sgi isn't a big problem per se, it doesn't block
> > further evolutions or anything like that, so if we can't find a
> > tester and it has to stay for a few more years, this really isn't a
> > problem for me.
> 
> If the merger of i2c-algo-sgi is as not something complex, then we
> can try to merge and apply at vino. Otherwise, we can just keep as-is.
> 
> PS.: probably you haven't noticed, but tea575x-tuner.c is still V4L1
> (one of your patches changed the header improperly, breaking sound
> build). 
> 
> Douglas,
> 
> As you've done several radio conversions to V4L2 API, maybe you can
> also handle this one.

yes.

Cheers,
Douglas

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Mauro Carvalho Chehab]

On Fri, 27 Feb 2009 10:50:57 -0300
Douglas Schilling Landgraf <dougsland@gmail.com> wrote:

> > Douglas,
> > 
> > As you've done several radio conversions to V4L2 API, maybe you can
> > also handle this one.
> 
> yes.

Hmm... too late, I've just converted it ;) My Internet connection dropped and I
was without email access, so... Well, it is done.

I'll commit the changesets right now. Could you please help reviewing it? I'll
also forward it to -alsa people.


Cheers,
Mauro

Re: Conversion of vino driver for SGI to not use the legacy decoder API

[Douglas Schilling Landgraf]

Hi there,

On Fri, 27 Feb 2009 12:37:14 -0300
Mauro Carvalho Chehab <mchehab@infradead.org> wrote:

> On Fri, 27 Feb 2009 10:50:57 -0300
> Douglas Schilling Landgraf <dougsland@gmail.com> wrote:
> 
> > > Douglas,
> > > 
> > > As you've done several radio conversions to V4L2 API, maybe you
> > > can also handle this one.
> > 
> > yes.
> 
> Hmm... too late, I've just converted it ;) My Internet connection
> dropped and I was without email access, so... Well, it is done.

ooops, no problem. I was not so far away in my conversion branch.

> I'll commit the changesets right now. Could you please help reviewing
> it? I'll also forward it to -alsa people.

Sure, reviewed. IMO, it's ok. 

Cheers,
Douglas