Trouble with i2c and bttv

Trouble with i2c and bttv

[Tim Boneko]

Hello!
I'm running linux for years now, but this is my very first bug report, 
and i hope it's helpful. If not, sorry for the bother...

On June 29, i pulled the latest i2c and lm_sensors drivers via CVS and 
got them working on my PC (MB: Asus A7N8X with nforce2 chipset, 
Kernel: 2.4.21-vanilla, a Hauppauge TV card (see log excerpt below). 
I did _not_ patch the kernel but replaced the kernel i2c modules with 
the downloaded+compiled ones.)
Worked fine so far, maybe except for the 4.08 volt reading appearing 
from time to time on various voltage measures, even "VCore1".
After such a successful installation i needed some relaxing and wanted 
to watch TV. "modprobe bttv" made my kernel go "Oops".
This module depends on i2c-algo-bit and i2c-core which were replaced 
by the i2c-drivers, so i guess there's a problem here. 
Below is the output of "lsmod" (before loading bttv.o) and an excerpt 
from my /var/log/kern.log after that.

Greetings,

	tim

lsmod:
Module                  Size  Used by    Not tainted
snd-mixer-oss          13528   0  (autoclean)
w83781d                22320   0  (unused)
eeprom                  3440   0  (unused)
i2c-proc                6260   0  [w83781d eeprom]
i2c-nforce2             3176   0  (unused)
i2c-core               13924   0  [w83781d eeprom i2c-proc 
i2c-nforce2]
serial                 46660   0  (autoclean)
snd-intel8x0           18052   2
snd-ac97-codec         40200   0  [snd-intel8x0]
snd-pcm                62016   2  [snd-intel8x0]
snd-timer              14820   0  [snd-pcm]
snd-page-alloc          5244   0  [snd-intel8x0 snd-pcm]
snd-mpu401-uart         3440   0  [snd-intel8x0]
snd-rawmidi            14016   0  [snd-mpu401-uart]
snd-seq-device          4304   0  [snd-rawmidi]
snd                    30532   0  [snd-mixer-oss snd-intel8x0 
snd-ac97-codec snd-pcm snd-timer snd-mpu401-uart snd-rawmidi 
snd-seq-device]
soundcore               3844   1  [snd]
nls_cp437               4380   1  (autoclean)
vfat                   10636   1  (autoclean)
fat                    32472   0  (autoclean) [vfat]
apm                    10248   1
nls_iso8859-15          3388   1
nls_cp850               3612   0  (unused)
printer                 7392   0
usb-storage            25104   0  (unused)
usb-ohci               19016   0  (unused)
usbcore                62528   0  [printer usb-storage usb-ohci]
unix                   15752  99  (autoclean)

/var/log/kern.log:

Jul  4 14:25:04 timbo kernel: bttv: driver version 0.7.104 loaded
Jul  4 14:25:04 timbo kernel: bttv: using 4 buffers with 2080k (8320k 
total) for capture
Jul  4 14:25:04 timbo kernel: bttv: Host bridge is PCI device 
10de:01e0 (nVidia Corporation)
Jul  4 14:25:04 timbo kernel: bttv: Bt8xx card found (0).
Jul  4 14:25:04 timbo kernel: bttv0: Bt878 (rev 2) at 01:0a.0, irq: 
11, latency: 32, mmio: 0xe8000000
Jul  4 14:25:04 timbo kernel: bttv0: detected: Hauppauge WinTV 
[card\x10], PCI subsystem ID is 0070:13eb
Jul  4 14:25:04 timbo kernel: bttv0: using: BT878(Hauppauge (bt878)) 
[card\x10,insmod option]
Jul  4 14:25:04 timbo kernel: bttv0: Hauppauge/Voodoo msp34xx: reset 
line init [5]
Jul  4 14:25:04 timbo kernel: Unable to handle kernel paging request 
at virtual address 0d83e14e
Jul  4 14:25:04 timbo kernel:  printing eip:
Jul  4 14:25:04 timbo kernel: 0d83e14e
Jul  4 14:25:04 timbo kernel: *pde = 00000000
Jul  4 14:25:04 timbo kernel: Oops: 0000
Jul  4 14:25:04 timbo kernel: CPU:    0
Jul  4 14:25:04 timbo kernel: EIP:    0010:[<0d83e14e>]    Not tainted
Jul  4 14:25:04 timbo kernel: EFLAGS: 00010292
Jul  4 14:25:04 timbo kernel: eax: e14f12e0   ebx: e14f12e0   ecx: 
e14f9764   edx: 00000000
Jul  4 14:25:04 timbo kernel: esi: e14f9728   edi: 00000001   ebp: 
00000000   esp: d468dbe0
Jul  4 14:25:04 timbo kernel: ds: 0018   es: 0018   ss: 0018
Jul  4 14:25:04 timbo kernel: Process modprobe (pid: 1443, 
stackpage‘68d000)
Jul  4 14:25:04 timbo kernel: Stack: e149d07b 801005ff 00000000 
c0237048 00000292 00000292 c0237048 e14f9764 
Jul  4 14:25:04 timbo kernel:        e149dbd4 e14f12e0 c0237048 
c0237048 c0237048 00000000 c0279dc0 e14f12e0 
Jul  4 14:25:04 timbo kernel:        e14f9764 e14f9728 00000001 
00000000 e146ac51 e14f9728 d468dc84 00000001 
Jul  4 14:25:04 timbo kernel: Call Trace:    
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-298885/128] 
[<e14f9764>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-295980/128] 
[<e14f12e0>] [<e14f12e0>]
Jul  4 14:25:04 timbo kernel:   [<e14f9764>] [<e14f9728>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-504751/128] 
[<e14f9728>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-296004/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-501226/128]
Jul  4 14:25:04 timbo kernel:   [<e14f9728>] [fbcon_scroll+1962/3216] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-500307/128] 
[<e14f9728>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-291648/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464416/128]
Jul  4 14:25:04 timbo kernel:   
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464816/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-475221/128] 
[<e14f9728>] [<e14f9728>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-494208/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-466826/128]
Jul  4 14:25:04 timbo kernel:   [<e14f9728>] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464416/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-466820/128] 
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-507581/128] 
[<e14f9728>] [vsnprintf+545/1104]
Jul  4 14:25:04 timbo kernel:   [<e14f972f>] [<e14f9580>] [<e14f9728>] 
[<e14f980c>] [<e14f972e>] [<e14f9728>]
Jul  4 14:25:04 timbo kernel:   
[ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-295623/128] 
[<e14f9728>] [<e14f4cd7>] [sprintf+31/48] [<e14f972d>] [<e14f4cd3>]
Jul  4 14:25:04 timbo kernel:   [<e14f9580>] [<e14f1724>] [<e14f9728>] 
[<e14f9580>] [<e14ed06a>] [<e14f9580>]
Jul  4 14:25:04 timbo kernel:   [pci_set_master+52/96] [<e14f9580>] 
[<e14edcf6>] [<e14f9580>] [<e14ed110>] [<e14f3e9c>]
Jul  4 14:25:04 timbo kernel:   [<e14f9580>] [printk+279/336] 
[<e14f5438>] [<e14f54a0>] [pci_announce_device+53/112] [<e14f5438>]
Jul  4 14:25:04 timbo kernel:   [<e14f54a0>] 
[pci_register_driver+92/96] [<e14f54a0>] [<e14ede61>] [<e14f54a0>] 
[sys_init_module+1201/1584]
Jul  4 14:25:04 timbo kernel:   [<e14e8060>] [<e14f4f3c>] [<e14e8060>] 
[system_call+51/56]
Jul  4 14:25:04 timbo kernel: 
Jul  4 14:25:04 timbo kernel: Code:  Bad EIP value.

Trouble with i2c and bttv

[Mark D. Studebaker]

i2c-2.8.0 isn't compatible with existing i2c drivers in the kernel due
to struct changes.

Tim Boneko wrote:
> Hello!
> I'm running linux for years now, but this is my very first bug report, 
> and i hope it's helpful. If not, sorry for the bother...
> 
> On June 29, i pulled the latest i2c and lm_sensors drivers via CVS and 
> got them working on my PC (MB: Asus A7N8X with nforce2 chipset, 
> Kernel: 2.4.21-vanilla, a Hauppauge TV card (see log excerpt below). 
> I did _not_ patch the kernel but replaced the kernel i2c modules with 
> the downloaded+compiled ones.)
> Worked fine so far, maybe except for the 4.08 volt reading appearing 
> from time to time on various voltage measures, even "VCore1".
> After such a successful installation i needed some relaxing and wanted 
> to watch TV. "modprobe bttv" made my kernel go "Oops".
> This module depends on i2c-algo-bit and i2c-core which were replaced 
> by the i2c-drivers, so i guess there's a problem here. 
> Below is the output of "lsmod" (before loading bttv.o) and an excerpt 
> from my /var/log/kern.log after that.
> 
> Greetings,
> 
> 	tim
> 
> lsmod:
> Module                  Size  Used by    Not tainted
> snd-mixer-oss          13528   0  (autoclean)
> w83781d                22320   0  (unused)
> eeprom                  3440   0  (unused)
> i2c-proc                6260   0  [w83781d eeprom]
> i2c-nforce2             3176   0  (unused)
> i2c-core               13924   0  [w83781d eeprom i2c-proc 
> i2c-nforce2]
> serial                 46660   0  (autoclean)
> snd-intel8x0           18052   2
> snd-ac97-codec         40200   0  [snd-intel8x0]
> snd-pcm                62016   2  [snd-intel8x0]
> snd-timer              14820   0  [snd-pcm]
> snd-page-alloc          5244   0  [snd-intel8x0 snd-pcm]
> snd-mpu401-uart         3440   0  [snd-intel8x0]
> snd-rawmidi            14016   0  [snd-mpu401-uart]
> snd-seq-device          4304   0  [snd-rawmidi]
> snd                    30532   0  [snd-mixer-oss snd-intel8x0 
> snd-ac97-codec snd-pcm snd-timer snd-mpu401-uart snd-rawmidi 
> snd-seq-device]
> soundcore               3844   1  [snd]
> nls_cp437               4380   1  (autoclean)
> vfat                   10636   1  (autoclean)
> fat                    32472   0  (autoclean) [vfat]
> apm                    10248   1
> nls_iso8859-15          3388   1
> nls_cp850               3612   0  (unused)
> printer                 7392   0
> usb-storage            25104   0  (unused)
> usb-ohci               19016   0  (unused)
> usbcore                62528   0  [printer usb-storage usb-ohci]
> unix                   15752  99  (autoclean)
> 
> /var/log/kern.log:
> 
> Jul  4 14:25:04 timbo kernel: bttv: driver version 0.7.104 loaded
> Jul  4 14:25:04 timbo kernel: bttv: using 4 buffers with 2080k (8320k 
> total) for capture
> Jul  4 14:25:04 timbo kernel: bttv: Host bridge is PCI device 
> 10de:01e0 (nVidia Corporation)
> Jul  4 14:25:04 timbo kernel: bttv: Bt8xx card found (0).
> Jul  4 14:25:04 timbo kernel: bttv0: Bt878 (rev 2) at 01:0a.0, irq: 
> 11, latency: 32, mmio: 0xe8000000
> Jul  4 14:25:04 timbo kernel: bttv0: detected: Hauppauge WinTV 
> [card\x10], PCI subsystem ID is 0070:13eb
> Jul  4 14:25:04 timbo kernel: bttv0: using: BT878(Hauppauge (bt878)) 
> [card\x10,insmod option]
> Jul  4 14:25:04 timbo kernel: bttv0: Hauppauge/Voodoo msp34xx: reset 
> line init [5]
> Jul  4 14:25:04 timbo kernel: Unable to handle kernel paging request 
> at virtual address 0d83e14e
> Jul  4 14:25:04 timbo kernel:  printing eip:
> Jul  4 14:25:04 timbo kernel: 0d83e14e
> Jul  4 14:25:04 timbo kernel: *pde = 00000000
> Jul  4 14:25:04 timbo kernel: Oops: 0000
> Jul  4 14:25:04 timbo kernel: CPU:    0
> Jul  4 14:25:04 timbo kernel: EIP:    0010:[<0d83e14e>]    Not tainted
> Jul  4 14:25:04 timbo kernel: EFLAGS: 00010292
> Jul  4 14:25:04 timbo kernel: eax: e14f12e0   ebx: e14f12e0   ecx: 
> e14f9764   edx: 00000000
> Jul  4 14:25:04 timbo kernel: esi: e14f9728   edi: 00000001   ebp: 
> 00000000   esp: d468dbe0
> Jul  4 14:25:04 timbo kernel: ds: 0018   es: 0018   ss: 0018
> Jul  4 14:25:04 timbo kernel: Process modprobe (pid: 1443, 
> stackpageÔ68d000)
> Jul  4 14:25:04 timbo kernel: Stack: e149d07b 801005ff 00000000 
> c0237048 00000292 00000292 c0237048 e14f9764 
> Jul  4 14:25:04 timbo kernel:        e149dbd4 e14f12e0 c0237048 
> c0237048 c0237048 00000000 c0279dc0 e14f12e0 
> Jul  4 14:25:04 timbo kernel:        e14f9764 e14f9728 00000001 
> 00000000 e146ac51 e14f9728 d468dc84 00000001 
> Jul  4 14:25:04 timbo kernel: Call Trace:    
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-298885/128] 
> [<e14f9764>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-295980/128] 
> [<e14f12e0>] [<e14f12e0>]
> Jul  4 14:25:04 timbo kernel:   [<e14f9764>] [<e14f9728>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-504751/128] 
> [<e14f9728>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-296004/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-501226/128]
> Jul  4 14:25:04 timbo kernel:   [<e14f9728>] [fbcon_scroll+1962/3216] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-500307/128] 
> [<e14f9728>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-291648/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464416/128]
> Jul  4 14:25:04 timbo kernel:   
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464816/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-475221/128] 
> [<e14f9728>] [<e14f9728>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-494208/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-466826/128]
> Jul  4 14:25:04 timbo kernel:   [<e14f9728>] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-464416/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-466820/128] 
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-507581/128] 
> [<e14f9728>] [vsnprintf+545/1104]
> Jul  4 14:25:04 timbo kernel:   [<e14f972f>] [<e14f9580>] [<e14f9728>] 
> [<e14f980c>] [<e14f972e>] [<e14f9728>]
> Jul  4 14:25:04 timbo kernel:   
> [ipt_MASQUERADE:__insmod_ipt_MASQUERADE_O/lib/modules/2.4.21/kernel/net/ipv+-295623/128] 
> [<e14f9728>] [<e14f4cd7>] [sprintf+31/48] [<e14f972d>] [<e14f4cd3>]
> Jul  4 14:25:04 timbo kernel:   [<e14f9580>] [<e14f1724>] [<e14f9728>] 
> [<e14f9580>] [<e14ed06a>] [<e14f9580>]
> Jul  4 14:25:04 timbo kernel:   [pci_set_master+52/96] [<e14f9580>] 
> [<e14edcf6>] [<e14f9580>] [<e14ed110>] [<e14f3e9c>]
> Jul  4 14:25:04 timbo kernel:   [<e14f9580>] [printk+279/336] 
> [<e14f5438>] [<e14f54a0>] [pci_announce_device+53/112] [<e14f5438>]
> Jul  4 14:25:04 timbo kernel:   [<e14f54a0>] 
> [pci_register_driver+92/96] [<e14f54a0>] [<e14ede61>] [<e14f54a0>] 
> [sys_init_module+1201/1584]
> Jul  4 14:25:04 timbo kernel:   [<e14e8060>] [<e14f4f3c>] [<e14e8060>] 
> [system_call+51/56]
> Jul  4 14:25:04 timbo kernel: 
> Jul  4 14:25:04 timbo kernel: Code:  Bad EIP value.
> 

Trouble with i2c and bttv

[Jean Delvare]

> i2c-2.8.0 isn't compatible with existing i2c drivers in the kernel due
> to struct changes.

BTW I'd like to work on this problem. I have a DC10+ board (zoran
driver) that suffers from the struct changes, and I really want to be
able to use bleeding edge sensors *and* occasionally watch TV. The
problem is that I just don't know how to fix the driver. Is there a
document somewhere explaining how to convert a driver from old structs
to new ones?

(If I succeed for my own board, I'll fix all the kernel drivers the same
way, providing someone can provide the first half of the patch, that is,
I2C itself.)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Trouble with i2c and bttv

[Mark D. Studebaker]

that would be great.
See CHANGES in i2c.
For bus drivers, take out the inc_use and dec_use entries in struct i2c_adapter,
remove the associated functions, and add an owner =THIS_MODULE in struct i2c_adapter.
Make sure everything is C99 initializers.
Make the same changes in struct i2c_driver (chip drivers)
Remove an argument in i2c_register_entry().

Jean Delvare wrote:
>>i2c-2.8.0 isn't compatible with existing i2c drivers in the kernel due
>>to struct changes.
> 
> 
> BTW I'd like to work on this problem. I have a DC10+ board (zoran
> driver) that suffers from the struct changes, and I really want to be
> able to use bleeding edge sensors *and* occasionally watch TV. The
> problem is that I just don't know how to fix the driver. Is there a
> document somewhere explaining how to convert a driver from old structs
> to new ones?
> 
> (If I succeed for my own board, I'll fix all the kernel drivers the same
> way, providing someone can provide the first half of the patch, that is,
> I2C itself.)
> 

Trouble with i2c and bttv

[Jean Delvare]

> that would be great.
> See CHANGES in i2c.
> For bus drivers, take out the inc_use and dec_use entries in struct
> i2c_adapter, remove the associated functions, and add an owner
> =THIS_MODULE in struct i2c_adapter. Make sure everything is C99
> initializers. Make the same changes in struct i2c_driver (chip
> drivers) Remove an argument in i2c_register_entry().

I will try this next week for the zoran driver.

I guess that we should send a patch with the new I2C layer to Marcelo
for the 2.4 kernel and wait for it to be applied before sending patches
for non-kernel drivers such as this zoran driver?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Trouble with i2c and bttv

[Mark D. Studebaker]

no, I think we need to send it all at once, it's a stable kernel

Jean Delvare wrote:
>>that would be great.
>>See CHANGES in i2c.
>>For bus drivers, take out the inc_use and dec_use entries in struct
>>i2c_adapter, remove the associated functions, and add an owner
>>=THIS_MODULE in struct i2c_adapter. Make sure everything is C99
>>initializers. Make the same changes in struct i2c_driver (chip
>>drivers) Remove an argument in i2c_register_entry().
> 
> 
> I will try this next week for the zoran driver.
> 
> I guess that we should send a patch with the new I2C layer to Marcelo
> for the 2.4 kernel and wait for it to be applied before sending patches
> for non-kernel drivers such as this zoran driver?
> 

Trouble with i2c and bttv

[Jean Delvare]

> no, I think we need to send it all at once, it's a stable kernel

I misexpressed myself. I mean we need to first have our patch (I2C layer
+ kernel drivers modifs) to be accepted before even having to help
non-kernel modules (such as the zoran one which I'm using) convert their
modules so that they will work with the new kernel.

BTW, I need a new-I2C-layer patch for the kernel before I can change the
zoran driver and test it. I guess that using our mkpatch script with
I2C-cvs should do it?

(This actually means that beginning with the zoran driver isn't the more
logical thing to do, but since this is the only module I'll be able to
test, better that way.)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Trouble with i2c and bttv

[Mark D. Studebaker]

yep, mkpatch should work great,
if it doesn't, let us know soon :)

Jean Delvare wrote:
>>no, I think we need to send it all at once, it's a stable kernel
> 
> 
> I misexpressed myself. I mean we need to first have our patch (I2C layer
> + kernel drivers modifs) to be accepted before even having to help
> non-kernel modules (such as the zoran one which I'm using) convert their
> modules so that they will work with the new kernel.
> 
> BTW, I need a new-I2C-layer patch for the kernel before I can change the
> zoran driver and test it. I guess that using our mkpatch script with
> I2C-cvs should do it?
> 
> (This actually means that beginning with the zoran driver isn't the more
> logical thing to do, but since this is the only module I'll be able to
> test, better that way.)
> 

Trouble with i2c and bttv

[Mark D. Studebaker]

What I mean is that we need to be prepared
to followup the i2c layer patch with the bttv fixup relatively quickly,
(you don't want the i2c patch to go in late in a release cycle either)
and the fixup may take some time, so in practice you may want to get started
on the fixup before you send in the i2c patch.



Jean Delvare wrote:
>>no, I think we need to send it all at once, it's a stable kernel
> 
> 
> I misexpressed myself. I mean we need to first have our patch (I2C layer
> + kernel drivers modifs) to be accepted before even having to help
> non-kernel modules (such as the zoran one which I'm using) convert their
> modules so that they will work with the new kernel.
> 
> BTW, I need a new-I2C-layer patch for the kernel before I can change the
> zoran driver and test it. I guess that using our mkpatch script with
> I2C-cvs should do it?
> 
> (This actually means that beginning with the zoran driver isn't the more
> logical thing to do, but since this is the only module I'll be able to
> test, better that way.)
> 

Trouble with i2c and bttv

[Jean Delvare]

> What I mean is that we need to be prepared
> to followup the i2c layer patch with the bttv fixup relatively
> quickly,(you don't want the i2c patch to go in late in a release cycle
> either) and the fixup may take some time, so in practice you may want
> to get started on the fixup before you send in the i2c patch.

I agree on all points. I'm on it as soon as possible, possibly even
today.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/