diff mbox

[v4l-dvb-maintainer] 2.6.30: missing audio device in bttv

Message ID 200906112222.50283.hverkuil@xs4all.nl (mailing list archive)
State RFC
Headers show

Commit Message

Hans Verkuil June 11, 2009, 8:22 p.m. UTC 
On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
> On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
> > Hi all,
> > 
> > With Linux 2.6.30 the BTTV driver for my WinTV card claims
> > 
> > 	bttv0: audio absent, no audio device found!
> > 
> > and audio does not work. This worked up to and including 2.6.29. Is this a
> > known issue? Does anyone have a fix or a patch for me to try?
> 
> You've no doubt compiled the bttv driver into the kernel and not as a module.
> 
> I've just pushed a fix for this to my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

I've also attached a diff against 2.6.30 since the patch in my tree is against
the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.

	Hans

Comments

Mauro Carvalho Chehab June 11, 2009, 10:20 p.m. UTC | #1 
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
> > On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
> > > Hi all,
> > > 
> > > With Linux 2.6.30 the BTTV driver for my WinTV card claims
> > > 
> > > 	bttv0: audio absent, no audio device found!
> > > 
> > > and audio does not work. This worked up to and including 2.6.29. Is this a
> > > known issue? Does anyone have a fix or a patch for me to try?
> > 
> > You've no doubt compiled the bttv driver into the kernel and not as a module.
> > 
> > I've just pushed a fix for this to my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> 
> I've also attached a diff against 2.6.30 since the patch in my tree is against
> the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.


> # All i2c modules must come first:

Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
proper solution is to make sure that i2c core got initialized before any i2c
client.

Jean,

is there any patch meant to fix the usage of i2c when I2C and drivers are compiled with 'Y' ?




Cheers,
Mauro
--
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
Hans Verkuil June 11, 2009, 10:26 p.m. UTC | #2 
On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
> Em Thu, 11 Jun 2009 22:22:50 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
> > On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
> > > On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
> > > > Hi all,
> > > > 
> > > > With Linux 2.6.30 the BTTV driver for my WinTV card claims
> > > > 
> > > > 	bttv0: audio absent, no audio device found!
> > > > 
> > > > and audio does not work. This worked up to and including 2.6.29. Is this a
> > > > known issue? Does anyone have a fix or a patch for me to try?
> > > 
> > > You've no doubt compiled the bttv driver into the kernel and not as a module.
> > > 
> > > I've just pushed a fix for this to my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> > 
> > I've also attached a diff against 2.6.30 since the patch in my tree is against
> > the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
> 
> 
> > # All i2c modules must come first:
> 
> Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
> proper solution is to make sure that i2c core got initialized before any i2c
> client.
> 
> Jean,
> 
> is there any patch meant to fix the usage of i2c when I2C and drivers are compiled with 'Y' ?

No, the i2c core is initialized just fine, but the msp3400 module is later in
the init sequence than bttv. So when bttv initializes and tries to find and
init the msp3400 module it won't find it.

There is something weird going on with either the tveeprom module and/or the
ir-kbd-i2c module. I'm looking into that.

Regards,

	Hans
Mauro Carvalho Chehab June 11, 2009, 11:07 p.m. UTC | #3 
Em Fri, 12 Jun 2009 00:26:13 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Jun 2009 22:22:50 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> > 
> > > On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
> > > > On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
> > > > > Hi all,
> > > > > 
> > > > > With Linux 2.6.30 the BTTV driver for my WinTV card claims
> > > > > 
> > > > > 	bttv0: audio absent, no audio device found!
> > > > > 
> > > > > and audio does not work. This worked up to and including 2.6.29. Is this a
> > > > > known issue? Does anyone have a fix or a patch for me to try?
> > > > 
> > > > You've no doubt compiled the bttv driver into the kernel and not as a module.
> > > > 
> > > > I've just pushed a fix for this to my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> > > 
> > > I've also attached a diff against 2.6.30 since the patch in my tree is against
> > > the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
> > 
> > 
> > > # All i2c modules must come first:
> > 
> > Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
> > proper solution is to make sure that i2c core got initialized before any i2c
> > client.
> > 
> > Jean,
> > 
> > is there any patch meant to fix the usage of i2c when I2C and drivers are compiled with 'Y' ?
> 
> No, the i2c core is initialized just fine,

I remember I had to commit a patch moving drivers/media to be compiled after to
i2c core due to a similar problem (git changeset a357482a1e8fdd39f0a58c33ed2ffd0f1becb825).

> but the msp3400 module is later in
> the init sequence than bttv. So when bttv initializes and tries to find and
> init the msp3400 module it won't find it.

> 
> There is something weird going on with either the tveeprom module and/or the
> ir-kbd-i2c module. I'm looking into that.

I suspect that we'll need to work with the initialization order after the new
i2c binding model to avoid such troubles.

I remember that we had a similar issue with alsa and saa7134. At the end, Linus [1]
had to do add this, as a quick hack (unfortunately, it is still there - it
seems that alsa guys forgot about that issue):

late_initcall(saa7134_alsa_init);

On that time, he suggested the usage of subsys_initcall() for alsa. I suspect
that we'll need to do the same for I2C and for V4L core. I'm not sure what
would be the alternative to be done with i2c ancillary drivers.

Maybe one alternative would be to use fs_initcall, that seems to be already
used by some non-fs related calls, like cpu governor [2].

[1] http://lkml.org/lkml/2007/3/23/285
[2] http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=fs_initcall


Cheers,
Mauro
--
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
Hans Verkuil June 11, 2009, 11:18 p.m. UTC | #4 
On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote:
> Em Fri, 12 Jun 2009 00:26:13 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
> > On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
> > > Em Thu, 11 Jun 2009 22:22:50 +0200
> > > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> > > 
> > > > On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
> > > > > On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > With Linux 2.6.30 the BTTV driver for my WinTV card claims
> > > > > > 
> > > > > > 	bttv0: audio absent, no audio device found!
> > > > > > 
> > > > > > and audio does not work. This worked up to and including 2.6.29. Is this a
> > > > > > known issue? Does anyone have a fix or a patch for me to try?
> > > > > 
> > > > > You've no doubt compiled the bttv driver into the kernel and not as a module.
> > > > > 
> > > > > I've just pushed a fix for this to my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> > > > 
> > > > I've also attached a diff against 2.6.30 since the patch in my tree is against
> > > > the newer v4l-dvb repository and doesn't apply cleanly against 2.6.30.
> > > 
> > > 
> > > > # All i2c modules must come first:
> > > 
> > > Argh! this is an ugly solution. This can be an workaround for 2.6.30, but the
> > > proper solution is to make sure that i2c core got initialized before any i2c
> > > client.
> > > 
> > > Jean,
> > > 
> > > is there any patch meant to fix the usage of i2c when I2C and drivers are compiled with 'Y' ?
> > 
> > No, the i2c core is initialized just fine,
> 
> I remember I had to commit a patch moving drivers/media to be compiled after to
> i2c core due to a similar problem (git changeset a357482a1e8fdd39f0a58c33ed2ffd0f1becb825).
> 
> > but the msp3400 module is later in
> > the init sequence than bttv. So when bttv initializes and tries to find and
> > init the msp3400 module it won't find it.
> 
> > 
> > There is something weird going on with either the tveeprom module and/or the
> > ir-kbd-i2c module. I'm looking into that.
> 
> I suspect that we'll need to work with the initialization order after the new
> i2c binding model to avoid such troubles.
> 
> I remember that we had a similar issue with alsa and saa7134. At the end, Linus [1]
> had to do add this, as a quick hack (unfortunately, it is still there - it
> seems that alsa guys forgot about that issue):
> 
> late_initcall(saa7134_alsa_init);
> 
> On that time, he suggested the usage of subsys_initcall() for alsa. I suspect
> that we'll need to do the same for I2C and for V4L core. I'm not sure what
> would be the alternative to be done with i2c ancillary drivers.
> 
> Maybe one alternative would be to use fs_initcall, that seems to be already
> used by some non-fs related calls, like cpu governor [2].

As long as the i2c modules come first there shouldn't be any problem. That's
pretty easy to arrange. So the i2c core inits first, then i2c drivers, then
v4l2 drivers. That's the proper order.

The ir-kbd-i2c module needed to be after the v4l2 modules since that still
relies on autoprobing. If it comes first, then it seems to mess up tveeprom
for some reason. Once ir-kbd-i2c no longer does autoprobing, then it probably
should move back to the other i2c modules.

Regards,

	Hans

> 
> [1] http://lkml.org/lkml/2007/3/23/285
> [2] http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=fs_initcall
> 
> 
> Cheers,
> Mauro
> 
> _______________________________________________
> v4l-dvb-maintainer mailing list
> v4l-dvb-maintainer@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
> 
>
Jean Delvare June 12, 2009, 8:04 a.m. UTC | #5 
On Fri, 12 Jun 2009 01:18:20 +0200, Hans Verkuil wrote:
> On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote:
> > I suspect that we'll need to work with the initialization order after the new
> > i2c binding model to avoid such troubles.
> > 
> > I remember that we had a similar issue with alsa and saa7134. At the end, Linus [1]
> > had to do add this, as a quick hack (unfortunately, it is still there - it
> > seems that alsa guys forgot about that issue):
> > 
> > late_initcall(saa7134_alsa_init);
> > 
> > On that time, he suggested the usage of subsys_initcall() for alsa. I suspect
> > that we'll need to do the same for I2C and for V4L core. I'm not sure what
> > would be the alternative to be done with i2c ancillary drivers.
> > 
> > Maybe one alternative would be to use fs_initcall, that seems to be already
> > used by some non-fs related calls, like cpu governor [2].
> 
> As long as the i2c modules come first there shouldn't be any problem. That's
> pretty easy to arrange. So the i2c core inits first, then i2c drivers, then
> v4l2 drivers. That's the proper order.

This is already what we have in 2.6.30 as far as I can see.

> The ir-kbd-i2c module needed to be after the v4l2 modules since that still
> relies on autoprobing. If it comes first, then it seems to mess up tveeprom
> for some reason. Once ir-kbd-i2c no longer does autoprobing, then it probably
> should move back to the other i2c modules.

Hopefully this will happen in the next few days :)
diff mbox

Patch

--- drivers/media/video/Makefile.org	2009-06-11 21:51:05.000000000 +0200
+++ drivers/media/video/Makefile	2009-06-11 21:54:48.000000000 +0200
@@ -12,6 +12,8 @@ 
 
 videodev-objs	:=	v4l2-dev.o v4l2-ioctl.o v4l2-device.o
 
+# V4L2 core modules
+
 obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
 ifeq ($(CONFIG_COMPAT),y)
   obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o
@@ -23,21 +25,16 @@ 
   obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o
 endif
 
-obj-$(CONFIG_VIDEO_TUNER) += tuner.o
+# All i2c modules must come first:
 
-obj-$(CONFIG_VIDEO_BT848) += bt8xx/
+obj-$(CONFIG_VIDEO_TUNER) += tuner.o
 obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
 obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
 obj-$(CONFIG_VIDEO_TDA9875) += tda9875.o
-
 obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
 obj-$(CONFIG_VIDEO_SAA5246A) += saa5246a.o
 obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o
-obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
-obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
-obj-$(CONFIG_VIDEO_W9966) += w9966.o
-
 obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
 obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
 obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
@@ -54,11 +51,40 @@ 
 obj-$(CONFIG_VIDEO_BT856) += bt856.o
 obj-$(CONFIG_VIDEO_BT866) += bt866.o
 obj-$(CONFIG_VIDEO_KS0127) += ks0127.o
+obj-$(CONFIG_VIDEO_VINO) += indycam.o
+obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
+obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
+obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
+obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
+obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
+obj-$(CONFIG_VIDEO_M52790) += m52790.o
+obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o
+obj-$(CONFIG_VIDEO_WM8775) += wm8775.o
+obj-$(CONFIG_VIDEO_WM8739) += wm8739.o
+obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
+obj-$(CONFIG_VIDEO_CX25840) += cx25840/
+obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
+obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV7670) 	+= ov7670.o
+obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
+obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 
-obj-$(CONFIG_VIDEO_ZORAN) += zoran/
+obj-$(CONFIG_SOC_CAMERA_MT9M001)	+= mt9m001.o
+obj-$(CONFIG_SOC_CAMERA_MT9M111)	+= mt9m111.o
+obj-$(CONFIG_SOC_CAMERA_MT9T031)	+= mt9t031.o
+obj-$(CONFIG_SOC_CAMERA_MT9V022)	+= mt9v022.o
+obj-$(CONFIG_SOC_CAMERA_OV772X)		+= ov772x.o
+obj-$(CONFIG_SOC_CAMERA_TW9910)		+= tw9910.o
 
+# And now the v4l2 drivers:
+
+obj-$(CONFIG_VIDEO_BT848) += bt8xx/
+obj-$(CONFIG_VIDEO_ZORAN) += zoran/
+obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
+obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
+obj-$(CONFIG_VIDEO_W9966) += w9966.o
 obj-$(CONFIG_VIDEO_PMS) += pms.o
-obj-$(CONFIG_VIDEO_VINO) += vino.o indycam.o
+obj-$(CONFIG_VIDEO_VINO) += vino.o
 obj-$(CONFIG_VIDEO_STRADIS) += stradis.o
 obj-$(CONFIG_VIDEO_CPIA) += cpia.o
 obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o
@@ -69,17 +95,7 @@ 
 obj-$(CONFIG_VIDEO_EM28XX) += em28xx/
 obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/
 obj-$(CONFIG_VIDEO_USBVISION) += usbvision/
-obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
-obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
 obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2/
-obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
-obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
-obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
-obj-$(CONFIG_VIDEO_M52790) += m52790.o
-obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o
-obj-$(CONFIG_VIDEO_WM8775) += wm8775.o
-obj-$(CONFIG_VIDEO_WM8739) += wm8739.o
-obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
 obj-$(CONFIG_VIDEO_OVCAMCHIP) += ovcamchip/
 obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
 obj-$(CONFIG_VIDEO_MXB) += mxb.o
@@ -92,19 +108,12 @@ 
 obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o
 obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
 obj-$(CONFIG_VIDEO_BTCX)  += btcx-risc.o
-obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 
 obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
 
-obj-$(CONFIG_VIDEO_CX25840) += cx25840/
-obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
-obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
 obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
 
 obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
-obj-$(CONFIG_VIDEO_OV7670) 	+= ov7670.o
-
-obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
 
 obj-$(CONFIG_USB_DABUSB)        += dabusb.o
 obj-$(CONFIG_USB_OV511)         += ov511.o
@@ -134,19 +143,14 @@ 
 obj-$(CONFIG_VIDEO_VIVI) += vivi.o
 obj-$(CONFIG_VIDEO_CX23885) += cx23885/
 
+obj-$(CONFIG_VIDEO_OMAP2)		+= omap2cam.o
+obj-$(CONFIG_SOC_CAMERA)		+= soc_camera.o
+obj-$(CONFIG_SOC_CAMERA_PLATFORM)	+= soc_camera_platform.o
+# soc-camera host drivers have to be linked after camera drivers
 obj-$(CONFIG_VIDEO_MX1)			+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX3)			+= mx3_camera.o
 obj-$(CONFIG_VIDEO_PXA27x)		+= pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)	+= sh_mobile_ceu_camera.o
-obj-$(CONFIG_VIDEO_OMAP2)		+= omap2cam.o
-obj-$(CONFIG_SOC_CAMERA)		+= soc_camera.o
-obj-$(CONFIG_SOC_CAMERA_MT9M001)	+= mt9m001.o
-obj-$(CONFIG_SOC_CAMERA_MT9M111)	+= mt9m111.o
-obj-$(CONFIG_SOC_CAMERA_MT9T031)	+= mt9t031.o
-obj-$(CONFIG_SOC_CAMERA_MT9V022)	+= mt9v022.o
-obj-$(CONFIG_SOC_CAMERA_OV772X)		+= ov772x.o
-obj-$(CONFIG_SOC_CAMERA_PLATFORM)	+= soc_camera_platform.o
-obj-$(CONFIG_SOC_CAMERA_TW9910)		+= tw9910.o
 
 obj-$(CONFIG_VIDEO_AU0828) += au0828/