Before the i2c redesign, it were enough to manually probe an i2c driver, for it to
attach at bttv (and other media drivers). However, this behavior is not supported anymore. Now the driver will try to autodetect and automatically load/attach tvaudio, based on the board number.

It is also possible to force it to probe a certain audio module with:

MODULE_PARM_DESC(audiodev, "specify audio device:\n"
                "\t\t-1 = no audio\n"
                "\t\t 0 = autodetect (default)\n"
                "\t\t 1 = msp3400\n"
                "\t\t 2 = tda7432\n"
                "\t\t 3 = tvaudio");

So, you may try to test it with audiodev=3. Yet, as the default is to autodetect,
it seems that the driver is not doing the right thing.

(In reply to comment #1)
> So, you may try to test it with audiodev=3. Yet, as the default is to
> autodetect,
> it seems that the driver is not doing the right thing.

I have the test but nothing changed:
options bttv radio=1 tuner=2 card=42 i2c_udelay=128 audiodev=3

[    7.355432] bttv: driver version 0.9.18 loaded
[    7.355437] bttv: using 8 buffers with 2080k (520 pages) each for capture
[    7.355481] bttv: Bt8xx card found (0).
[    7.359782] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[    7.359793]   alloc irq_desc for 17 on node -1
[    7.359795]   alloc kstat_irqs on node -1
[    7.359807] bttv 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
[    7.359819] bttv0: Bt878 (rev 17) at 0000:01:09.0, irq: 17, latency: 32, mmio: 0xfdeff000
[    7.360278] bttv0: using: ProVideo PV951 [card=42,insmod option]
[    7.360280] IRQ 17/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
[    7.360321] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init]
[    7.387869] bttv0: tuner type=2
[    7.642878] bttv0: audio absent, no audio device found!
[    7.744336] Chip ID is not zero. It is not a TEA5767
[    7.744405] tuner 2-0060: chip found @ 0xc0 (bt878 #0 [sw])
[    7.754286] tuner-simple 2-0060: creating new instance
[    7.754290] tuner-simple 2-0060: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
[    7.766508] bttv0: registered device video0
[    7.766546] bttv0: registered device vbi0
[    7.766585] bttv0: registered device radio0
[    7.766605] bttv0: PLL: 28636363 => 35468950 .. ok

And module tvaudio real loaded but don't initialized but the module load without audiodev=3 always.

Sorry, I didn't quite understood your last sentence in comment #2. Is the tvaudio module loaded or not?

And another question: is the module ir-kbd-i2c loaded as well?

Some background information: if the module ir-kbd-i2c is loaded, then that might block tvaudio from being activated since the same chip handles both audio and IR.

If ir-kbd-i2c is not loaded, then we go to the next phase where I'll be adding some debug code.

BTW, is the card that you have for sale somewhere? This card is one of the more interesting devices to have.

(In reply to comment #3)
> Sorry, I didn't quite understood your last sentence in comment #2. Is the
> tvaudio module loaded or not?
The module loaded in any cases.
 
> And another question: is the module ir-kbd-i2c loaded as well?
The module did not loaded.

This modules map I have on 2.6.32:
[root@roman ~]# lsmod | grep i2c
i2c_algo_bit            4748  1 bttv
i2c_nforce2             5257  0
i2c_core               20020  12 nvidia,tuner_simple,tea5767,tuner,tvaudio,tda7432,bttv,v4l2_common,videodev,i2c_algo_bit,tveeprom,i2c_nforce2

[root@roman ~]# lsmod | grep bttv
bttv                  111144  1
v4l2_common            15364  4 tuner,tvaudio,tda7432,bttv
videodev               33800  6 tuner,tvaudio,tda7432,bttv,v4l2_common
ir_common              38803  1 bttv
i2c_algo_bit            4748  1 bttv
videobuf_dma_sg        10390  1 bttv
videobuf_core          15878  2 bttv,videobuf_dma_sg
btcx_risc               3680  1 bttv
tveeprom               11227  1 bttv
i2c_core               20020  12 nvidia,tuner_simple,tea5767,tuner,tvaudio,tda7432,bttv,v4l2_common,videodev,i2c_algo_bit,tveeprom,i2c_nforce2

> BTW, is the card that you have for sale somewhere? 
The card is mostly old card. I bought the card in 2001 year.

OK, thanks for the information.

A few other simple questions:

Is this the only TV card in your PC?

Can you attach the full dmesg output and lsmod output to this bug report?

What is the output of: ls /sys/bus/i2c/devices/

If you see a directory name there ending at '-004b', then please give the output of 'cat /sys/bus/i2c/devices/X-004b/modalias'. X is probably 2 based on the dmesg output you gave earlier. 

Do you have some programming experience? (C in particular)

The next step will probably be that I provide some code for you to compile in order to figure out what is going on.

If this is the only TV card, then the fact that the tvaudio module is loaded indicates that bttv is doing the right thing. So the problem must be somewhere else.

(In reply to comment #6)
> Is this the only TV card in your PC?
What mean "only TV card"?
Into manual to the card wrote:
"TV/FM Capture card (PCI - BUS Tuner/Capture Card)"
 
> Can you attach the full dmesg output and lsmod output to this bug report?
OK. I will.

> What is the output of: ls /sys/bus/i2c/devices/
[root@roman tmp]# ls /sys/bus/i2c/devices/
2-004b  2-0060  i2c-0  i2c-1  i2c-2  i2c-3  i2c-4  i2c-5

> If you see a directory name there ending at '-004b', then please give the
> output of 'cat /sys/bus/i2c/devices/X-004b/modalias'. X is probably 2 based
> on
> the dmesg output you gave earlier. 
[root@roman tmp]# cat /sys/bus/i2c/devices/2-004b/modalias
i2c:ir_video

> Do you have some programming experience? (C in particular)
Yes I have.
 
> The next step will probably be that I provide some code for you to compile in
> order to figure out what is going on.
OK
 
> If this is the only TV card, then the fact that the tvaudio module is loaded
> indicates that bttv is doing the right thing. So the problem must be
> somewhere
> else.
Yes, this is TV card and chip pic16c54 for audio.

Created attachment 25014 [details]
dmesg.log

dmesg call on 2.6.32 kernel.

Created attachment 25015 [details]
lsmod.log

lsmod call on 2.6.32 kernel.

Created attachment 25016 [details]
lspci.log

lspci for system with TV card.

With 'Only TV card' I meant 'Is this the only PCI TV card in your PC'. But from the lspci log it is clear that it is.

Anyway, the modalias output strongly suggests that it is associated with the i2c IR module instead of the audio module.

Jean, can you give some i2c insights here?

The core problem is that the ir-kbd-i2c module and the tvaudio module both recognize the same i2c multifunction device. But tvaudio is loaded while ir-kbd-i2c isn't. So why is apparently tvaudio still not probing this device?

We had a discussion about this March 2009 on the linux-media list (thread subject was "bttv, tvaudio and ir-kbd-i2c probing conflict").

Reading back I gather that it basically boiled down to the fact that currently you need to do a lot of work if you want to support multifunction i2c devices. And nobody did that work.

Not unreasonable given that this particular old board is the only one with that problem that I am aware of.

However, having the ir module somehow blocking the audio from working is not right. Audio without IR support is acceptable, the other way around isn't.

Is there an easy way for Roman to somehow disable the IR part?

Hans, I will try to answer your i2c questions.

In the new (standard) i2c device driver binding model, the driver binding is separate from the device declarations. This means that a device can be instantiated at a given address, but no driver is (yet) bound to it. This is what happens here: the bttv bridge driver instantiates an "ir_video" i2c device at address 0x4b, but the corresponding driver (ir-kbd-i2c) isn't loaded. We did not enable driver auto-loading for this device, because (if I recall correctly) there are two possible drivers (ir-kbd-i2c and lirc_i2c) and we wanted to let the user pick the one they preferred. Probably, if Roman would run "modprobe ir-kbd-i2c" he would get IR support.

Now, it is not possible to instantiate two i2c devices at the same address, so presumably the bttv bridge driver also attempts to instantiate a "tvaudio" device at the same address, but that fails because the address is already in use. Ideally, v4l2_i2c_new_subdev() would log the failure, but I guess it was made quiet on purpose because sometimes we expect failures when we are only probing for devices which may or may not be there? Building a kernel with CONFIG_I2C_DEBUG_CORE=y would probably show the address conflict.

I think that the easiest approach would be to add a "disable_ir" module parameter to bttv, as we already have for cx231xx, em28xx and saa7134. If we can prevent the "ir_video" device from being instantiated, the "tvaudio" device would be created and sound should work.

Alternatively, why are we declaring the IR device at all on this specific card? In the current state of things, IR and audio can't work together and it's pretty obvious that users want audio and can live without IR. So we could simply drop IR support on that specific board altogether.

Another thing I would like to comment on:

(In reply to comment #11)
> Reading back I gather that it basically boiled down to the fact that
> currently you need to do a lot of work if you want to support multifunction
> i2c devices. And nobody did that work.

That's not entirely true. Supporting multifunction i2c devices work fine as long as you have the support for all functions in the same driver. There are a couple drivers doing this in the kernel tree already (fschmd and w83793 for example). The problem is that this doesn't mix well with the design of the old tvaudio and ir-kbd-i2c drivers which attempt to support many very different chips. 

Obviously, merging tvaudio and ir-kbd-i2c together isn't an option. The right thing to do here would be to move pic16c54 support to a separate driver which would take care of both the audio and the IR functions, but just for this one chip. This shouldn't be too hard and should work fine.

Created attachment 25051 [details]
Proposed workaround

Roman, could you please test this patch? It moves I2C IR initialization after audio initialization, so hopefully you should get your sound back (and lose IR but I seem to understand you don't really care.) If it still doesn't work, I have also added a new "disable_ir" module parameter which you can pass to plain disable IR support.

Thanks you, Jean and Hans. Sound has really returned back. And parameter "disable_ir" I haven't used:
[ 2206.644826] bttv: driver version 0.9.18 loaded
[ 2206.644830] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 2206.644881] bttv: Bt8xx card found (0).
[ 2206.644894] bttv0: Bt878 (rev 17) at 0000:01:09.0, irq: 17, latency: 32, mmio: 0xfdeff000
[ 2206.644932] bttv0: using: ProVideo PV951 [card=42,insmod option]
[ 2206.644935] IRQ 17/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
[ 2206.644977] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init]
[ 2206.645022] bttv0: tuner type=2
[ 2206.766860] tvaudio: TV audio decoder + audio/video mux driver
[ 2206.766863] tvaudio: known chips: tda9840, tda9873h, tda9874h/a, tda9875, tda9850, tda9855, tea6300, tea6320, tea6420, tda8425, pic16c54 (PV951), ta8874z
[ 2206.766875] tvaudio 2-004b: chip found @ 0x96
[ 2206.766878] tvaudio 2-004b: pic16c54 (PV951) found @ 0x96 (bt878 #0 [sw])
[ 2206.766880] tvaudio 2-004b: matches: audiomux.
[ 2206.828163] Chip ID is not zero. It is not a TEA5767
[ 2206.828238] tuner 2-0060: chip found @ 0xc0 (bt878 #0 [sw])
[ 2206.833473] tuner-simple 2-0060: creating new instance
[ 2206.833476] tuner-simple 2-0060: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
[ 2206.845713] bttv0: registered device video0
[ 2206.845757] bttv0: registered device vbi0
[ 2206.845798] bttv0: registered device radio0
[ 2206.845811] tvaudio 2-004b: chip_write: reg2=0x10
[ 2206.853294] tvaudio 2-004b: chip_write: reg2=0x10
[ 2206.860777] bttv0: PLL: 28636363 => 35468950 .
[ 2206.861208] bttv0: PLL: 28636363 => 35468950 .
[ 2206.876726] tvaudio 2-004b: chip_write: reg2=0x10
[ 2206.884207]  ok
[ 2206.887418]  ok
[ 2206.908464] tvaudio 2-004b: chip_write: reg2=0x10
[ 2206.928063] tvaudio 2-004b: chip_write: reg2=0x10
[ 2206.959799] tvaudio 2-004b: chip_write: reg2=0x10

Will you include the path into main kernel branch?

Patches sent to the linux-media mailing list.

Patch is in mainline now:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2434466432464110b5307757e0285dd41f15512e

It should be backported to 2.6.32-stable. Michael, can you please take care of this?

(In reply to comment #17)
> Patch is in mainline now:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2434466432464110b5307757e0285dd41f15512e
> 
> It should be backported to 2.6.32-stable. Michael, can you please take care
> of
> this?

As the patch as CC: stable@kernel.org, it should already be on stable queue. Action is needed only if the patch doesn't apply as-is.

Thanks!
All work fine at kernel 2.6.32.
Close bug.