2.6.30: missing audio device in bttv
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?
Cheers,
- Udo
Output for 2.6.29:
------------------
Linux video capture interface: v2.00
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tuner' 0-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 0-0042: creating new instance
tda9887 0-0042: tda988[5/6/7] found
tuner' 0-0061: chip found @ 0xc2 (bt878 #0 [sw])
tveeprom 0-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 0-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 0-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 0-0050: audio processor is MSP3410D (idx 5)
tveeprom 0-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner-simple 0-0061: creating new instance
tuner-simple 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
bttv0: PLL: 28636363 => 35468950 .. ok
Output for 2.6.30:
------------------
Linux video capture interface: v2.00
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
bttv0: audio absent, no audio device found!
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
Signature · 4 lines
Dipl.-Inf. Udo Steinberg Technische Universität Dresden http://os.inf.tu-dresden.de/~us15 Institute for System Architecture Tel: +49 351 463 38401 D-01062 Dresden Fax: +49 351 463 38284
Quoted 8 lines · 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
Regards,
Hans
Quoted 70 lines
Cheers,
- Udo
Output for 2.6.29:
------------------
Linux video capture interface: v2.00
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio:0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0:IRQF_DISABLEDis not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tuner' 0-0042: chip found @0x84(bt878 #0 [sw])
tda9887 0-0042: creating new instance
tda9887 0-0042: tda988[5/6/7] found
tuner' 0-0061: chip found @0xc2(bt878 #0 [sw])
tveeprom 0-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 0-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 0-0050: TV standards PAL(B/G) (eeprom0x04)
tveeprom 0-0050: audio processor is MSP3410D (idx 5)
tveeprom 0-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner-simple 0-0061: creating new instance
tuner-simple 0-0061: type set to 5 (PhilipsPAL_BG(FI1216 and compatibles))
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
bttv0: PLL: 28636363 => 35468950 .. okOutput for 2.6.30:
------------------
Linux video capture interface: v2.00
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio:0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0:IRQF_DISABLEDis not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 1-0050: TV standards PAL(B/G) (eeprom0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @0x84(bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
tuner 1-0061: chip found @0xc2(bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (PhilipsPAL_BG(FI1216 and compatibles))
bttv0: audio absent, no audio device found!
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Quoted 5 lines · On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
Quoted 4 lines · 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
Quoted 8 lines
Quoted 4 lines
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
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
media/video/Makefile renamed from media/video/Makefile.org +39 -35
@@ -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/
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil <[email protected]> escreveu:
Quoted 13 lines · On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
Quoted 12 lines · On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 1 line
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
Quoted 24 lines · On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil <[email protected]> escreveu:Quoted 13 lines · On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
Quoted 12 lines · On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 1 line
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:
Quoted 7 lines
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
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Em Fri, 12 Jun 2009 00:26:13 +0200
Hans Verkuil <[email protected]> escreveu:
Quoted 29 lines · On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
Quoted 28 lines
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil <[email protected]> escreveu:Quoted 13 lines · On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
Quoted 12 lines · On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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).
Quoted 7 lines
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
Quoted 56 lines · On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote:
Em Fri, 12 Jun 2009 00:26:13 +0200
Hans Verkuil <[email protected]> escreveu:Quoted 29 lines · On Friday 12 June 2009 00:20:52 Mauro Carvalho Chehab wrote:
Quoted 28 lines
Em Thu, 11 Jun 2009 22:22:50 +0200
Hans Verkuil <[email protected]> escreveu:Quoted 13 lines · On Thursday 11 June 2009 22:18:10 Hans Verkuil wrote:
Quoted 12 lines · On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
Quoted 8 lines
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.
Quoted 7 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 3 lines
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/mediato be compiled after to i2c core due to a similar problem (git changeseta357482a1e8fdd39f0a58c33ed2ffd0f1becb825).Quoted 7 lines
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):
Quoted 8 lines
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
Quoted 14 lines
[1] http://lkml.org/lkml/2007/3/23/285
[2] http://tomoyo.sourceforge.jp/cgi-bin/lxr/ident?i=fs_initcallCheers,
Mauro_______________________________________________
v4l-dvb-maintainer mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
Quoted 14 lines · Hans Verkuil
Quoted 13 lines · 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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 4 lines
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 :)
Signature · 1 line
Jean Delvare
On Thu, 11 Jun 2009 22:18:10 +0200 Hans Verkuil (HV) wrote:
HV> On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
HV> > Hi all,
HV> >
HV> > With Linux 2.6.30 the BTTV driver for my WinTV card claims HV> >
HV> > bttv0: audio absent, no audio device found!
HV> >
HV> > and audio does not work. This worked up to and including 2.6.29. Is HV> > this a known issue? Does anyone have a fix or a patch for me to try? HV>
HV> You've no doubt compiled the bttv driver into the kernel and not as a HV> module.
HV>
HV> I've just pushed a fix for this to my tree:
HV> http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Yes, I've compiled bttv into the kernel. I've (hopefully correctly) ported the commit http://www.linuxtv.org/hg/~hverkuil/v4l-dvb/rev/820630b2b12f
to 2.6.30. Now I'm getting:
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-0018/ir0 [bt878 #0 [sw]] i2c-adapter i2c-1: sendbytes: NAK bailout.
tveeprom 1-0050: Huh, no eeprom present (err=-5)?
tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or not a Hauppauge eeprom.
bttv0: Hauppauge eeprom indicates model#0
bttv0: tuner absent
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950
Cheers,
- Udo
Quoted 33 lines · On Thursday 11 June 2009 23:38:17 Udo A. Steinberg wrote:
On Thu, 11 Jun 2009 22:18:10 +0200 Hans Verkuil (HV) wrote:
HV> On Thursday 11 June 2009 22:14:02 Udo A. Steinberg wrote:
HV> > Hi all,
HV> >
HV> > With Linux 2.6.30 the BTTV driver for my WinTV card claims HV> >
HV> > bttv0: audio absent, no audio device found!
HV> >
HV> > and audio does not work. This worked up to and including 2.6.29. Is HV> > this a known issue? Does anyone have a fix or a patch for me to try? HV>
HV> You've no doubt compiled the bttv driver into the kernel and not as a HV> module.
HV>
HV> I've just pushed a fix for this to my tree:
HV> http://www.linuxtv.org/hg/~hverkuil/v4l-dvbYes, I've compiled bttv into the kernel. I've (hopefully correctly) ported the commit http://www.linuxtv.org/hg/~hverkuil/v4l-dvb/rev/820630b2b12f
to 2.6.30. Now I'm getting:bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio:0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0:IRQF_DISABLEDis not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-0018/ir0 [bt878 #0 [sw]]
Quoted 8 lines
i2c-adapter i2c-1: sendbytes: NAK bailout.
tveeprom 1-0050: Huh, no eeprom present (err=-5)?
tveeprom 1-0050: Encountered bad packet header [00]. Corrupt or not a Hauppauge eeprom.
bttv0: Hauppauge eeprom indicates model#0
bttv0: tuner absent
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950
Hmm, my patch needs a bit more work. But to get your setup working try to revert the change you made and do just this:
Go to drivers/media/video/Makefile and move this line:
obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
in front of this line:
obj-$(CONFIG_VIDEO_BT848) += bt8xx/
Recompile and see if that is working.
I got the tveeprom error as well when I tested with ivtv, but I thought that had something to do with the ivtv driver. Apparently not, so I need to dig a bit more into these dependencies.
Regards,
Hans
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
On Thu, 11 Jun 2009 23:46:48 +0200 Hans Verkuil (HV) wrote:
HV> Hmm, my patch needs a bit more work. But to get your setup working try to HV> revert the change you made and do just this:
HV>
HV> Go to drivers/media/video/Makefile and move this line:
HV>
HV> obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
HV>
HV> in front of this line:
HV>
HV> obj-$(CONFIG_VIDEO_BT848) += bt8xx/
HV>
HV> Recompile and see if that is working.
HV>
HV> I got the tveeprom error as well when I tested with ivtv, but I thought HV> that had something to do with the ivtv driver. Apparently not, so I need HV> to dig a bit more into these dependencies.
Switching those two lines seems to improve the dependencies for my setup. However, audio still does not work. Furthermore, switching channels in tvtime now hangs for up to 5 seconds. strace -r shows that it spends a lot of time in the second ioctl.
0.000085 ioctl(4, VIDIOC_G_TUNER, 0xbfef1d70) = 0
0.000385 select(5, [4], NULL, NULL, {3, 0}) = 1 (in [4], left {2, 988069}) 0.012006 ioctl(4, VIDIOC_DQBUF, 0xbfef1dc4) = 0
The current dmesg output is as follows:
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio: 0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 1-0050: TV standards PAL(B/G) (eeprom 0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @ 0x84 (bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
tuner 1-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) msp3400 1-0040: MSP3410D-B4 found @ 0x80 (bt878 #0 [sw])
msp3400 1-0040: msp3400 supports nicam, mode is autodetect
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
Cheers,
- Udo
Quoted 50 lines · On Friday 12 June 2009 00:35:26 Udo A. Steinberg wrote:
On Thu, 11 Jun 2009 23:46:48 +0200 Hans Verkuil (HV) wrote:
HV> Hmm, my patch needs a bit more work. But to get your setup working try to HV> revert the change you made and do just this:
HV>
HV> Go todrivers/media/video/Makefileand move this line:
HV>
HV> obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
HV>
HV> in front of this line:
HV>
HV> obj-$(CONFIG_VIDEO_BT848) += bt8xx/
HV>
HV> Recompile and see if that is working.
HV>
HV> I got the tveeprom error as well when I tested with ivtv, but I thought HV> that had something to do with the ivtv driver. Apparently not, so I need HV> to dig a bit more into these dependencies.Switching those two lines seems to improve the dependencies for my setup. However, audio still does not work. Furthermore, switching channels in tvtime now hangs for up to 5 seconds. strace -r shows that it spends a lot of time in the second ioctl.
0.000085
ioctl(4, VIDIOC_G_TUNER, 0xbfef1d70)= 0
0.000385select(5, [4], NULL, NULL, {3, 0})= 1 (in [4], left {2, 988069}) 0.012006ioctl(4, VIDIOC_DQBUF, 0xbfef1dc4)= 0The current dmesg output is as follows:
bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv 0000:06:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
bttv0: Bt878 (rev 2) at 0000:06:00.0, irq: 21, latency: 32, mmio:0x50001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
IRQ 21/bttv0:IRQF_DISABLEDis not guaranteed on shared IRQs
bttv0: gpio: en=00000000, out=00000000 in=00ffffdb [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
tveeprom 1-0050: Hauppauge model 37284, rev B221, serial# 3546046 tveeprom 1-0050: tuner model is Philips FM1216 (idx 21, type 5) tveeprom 1-0050: TV standards PAL(B/G) (eeprom0x04)
tveeprom 1-0050: audio processor is MSP3410D (idx 5)
tveeprom 1-0050: has radio
bttv0: Hauppauge eeprom indicates model#37284
bttv0: tuner type=5
tuner 1-0042: chip found @0x84(bt878 #0 [sw])
tda9887 1-0042: creating new instance
tda9887 1-0042: tda988[5/6/7] found
Quoted 8 lines
tuner 1-0061: chip found @
0xc2(bt878 #0 [sw])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 5 (PhilipsPAL_BG(FI1216 and compatibles)) msp3400 1-0040: MSP3410D-B4 found @0x80(bt878 #0 [sw])
msp3400 1-0040: msp3400 supports nicam, mode is autodetect
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
Hmm, this looks OK.
I've fixed the problem in my original patch. I've attached the new version. It works fine with ivtv, the problems with reading the eeprom are now fixed. Please test and if it still doesn't work then I'll have to install my bttv card in my PC and test again. But that will be tomorrow evening.
BTW, it would be nice if you can confirm that everything is working fine if you compile bttv as a module. Just to make sure that this is related to the in-kernel build. The other person who had this problem (and who had a very similar card) said that it was working after moving that line in the Makefile.
Regards,
Hans
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
media/video/Makefile renamed from media/video/Makefile.org +41 -36
@@ -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,15 @@ 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_IR_I2C) += ir-kbd-i2c.o +obj-$(CONFIG_VIDEO_TUNER) += tuner.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 +50,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 +94,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 +107,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,24 +142,21 @@ 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/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ +obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o + EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends EXTRA_CFLAGS += -Idrivers/media/common/tuners
On Fri, 12 Jun 2009 01:01:59 +0200 Hans Verkuil (HV) wrote:
HV> I've fixed the problem in my original patch. I've attached the new HV> version. It works fine with ivtv, the problems with reading the eeprom HV> are now fixed. Please test and if it still doesn't work then I'll have HV> to install my bttv card in my PC and test again. But that will be HV> tomorrow evening.
Reading the eeprom works with your patch.
HV> BTW, it would be nice if you can confirm that everything is working fine HV> if you compile bttv as a module. Just to make sure that this is related HV> to the in-kernel build. The other person who had this problem (and who HV> had a very similar card) said that it was working after moving that line HV> in the Makefile.
That works, too.
Meanwhile I've figured out that the audio problems are related to ALSA. The BTTV audio signal is fed via a cable to the line-in of my on-board sound. I've verified that there is audio going over that cable. So I'll talk to the ALSA folks about the issue.
Thanks for your help, Hans.
Cheers,
- Udo