Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model (v2)
On Wed, Apr 29, 2009 at 8:29 AM, Jean Delvare wrote: > On Fri, 17 Apr 2009 22:29:27 +0200, Jean Delvare wrote: >> Here comes an update of my conversion of ir-kbd-i2c to the new i2c >> binding model. I've split it into 6 pieces for easier review. (...) > > Did anyone test these patches, please? Hello Jean, I'm still going to get these tested this week for em28xx. I got sidetracked yesterday on a race condition I discovered in the dvb core. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model (v2)
Hi Jean, Am Mittwoch, den 29.04.2009, 14:29 +0200 schrieb Jean Delvare: > On Fri, 17 Apr 2009 22:29:27 +0200, Jean Delvare wrote: > > Here comes an update of my conversion of ir-kbd-i2c to the new i2c > > binding model. I've split it into 6 pieces for easier review. (...) > > Did anyone test these patches, please? it took me about two years to fix the obviously wrong radio configuration on the MSI t...@nywhere Plus, also some other input was wrong and similar happened on other cards. To get no reply unfortunately happens quite often and it is not meant as an offense, but either you don't reach people with that hardware on the list currently or they are simply ignorant for some even most simple test. To have done most tricky things previously does not prevent them from ignoring simple test requests. I don't have anything using ir-kbd-i2c. Also don't know anything about the subscribers count on linux-media currently. On video4linux alone it have been almost 2500 in average. Maybe a test repo on linuxtv.org might help, without the need to apply patches manually and also mail to the old lists for testers? Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model (v2)
On Fri, 17 Apr 2009 22:29:27 +0200, Jean Delvare wrote: > Here comes an update of my conversion of ir-kbd-i2c to the new i2c > binding model. I've split it into 6 pieces for easier review. (...) Did anyone test these patches, please? -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model (v2)
Hi all, Here comes an update of my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 6 pieces for easier review. Firstly there is 1 preliminary patch: 01-ir-kbd-i2c-dont-abuse-client-name.patch Then 3 patches doing the actual conversion: 02-ir-kbd-i2c-convert-to-new-style.patch 03-configure-ir-receiver.patch 04-ir-kbd-i2c-dont-bind-to-unsupported-devices.patch And lastly 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: 04-saa7134-input-cleanup-msi-ir.patch 05-saa7134-input-cleanup-avermedia-cardbus.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27 and 2.6.29. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. The main difference with my initial patch set is that the ir-kbd-i2c devices are named ir_video instead of ir-kbd. The new name was chosen neutral to make it clear that alternative drivers can bind to these devices if so is the user's desire (lirc comes to mind). Such drivers will need to be updated, but with the legacy binding model going away, that had to happen anyway. I'll post all 6 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
Hi Andy, On Mon, 06 Apr 2009 07:56:22 -0400, Andy Walls wrote: > On Mon, 2009-04-06 at 10:54 +0200, Jean Delvare wrote: > > Thanks a lot for the testing! > > You're welcome. > > Sorry for being such a pain to what I suspect you hoped was to be a > "simple" change. You must be kidding. For one thing, I never expected it to be a simple change ;) For another, you're helping me a lot with your comments and testing. Thanks! -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
On Mon, 2009-04-06 at 10:54 +0200, Jean Delvare wrote: > Hi Andy, > Note that struct IR_i2c_init_data only contains the fields I needed at > the moment, but it would be trivial to extend it to allow bridge > drivers to pass more setup information if needed, for example ir_type. Yeah, I could have mucked with it myself, but communicating back the whole merged diff would have been a hassle. I was just testing anyway. > > Success. > > OK, good to know that adding support for the cx18 will be possible and > easy. I propose that we postpone this addition until after my code is > merged though, to avoid making the situation more complex than it > already is. Yeah. So far one user has asked for it. > Thanks a lot for the testing! You're welcome. Sorry for being such a pain to what I suspect you hoped was to be a "simple" change. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
Hi Andy, On Sun, 05 Apr 2009 20:22:59 -0400, Andy Walls wrote: > I tested your original patch set so you can get some real feedback. The > news is good, but I'll bore you with the details first. :) > > > 1. My setup: > > HVR-1600: Hauppauge model 74041, rev C5B2, serial# 891351 > has no radio, has IR receiver, has IR transmitter (Zilog Z8F0811) > > Hauppauge Remote: Grey top side & black bottom side; > with 4 colored buttons Red, Green, Yellow, Blue; > Numbers inside battery cover: > A415-HPG > M25909070211590 > > uname -a: > Linux morgan.walls.org 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 > EST 2008 x86_64 x86_64 x86_64 GNU/Linux > > v4l-dvb: pulled this morning. > > > 2. OK, my first test had no effect, because I'm an idiot. :) > In the cx18 driver, I didn't remove the I2C addresses in your original > patch, and I didn't add 0x71 as a valid address. > > > > 3. My second test had bad results: > > # modprobe ir-kbd-i2c debug=3 hauppauge=1 > > Message from sysl...@morgan at Apr 5 18:47:14 ... > kernel:Oops: 0010 [1] SMP > > Message from sysl...@morgan at Apr 5 18:47:14 ... > kernel:Code: Bad RIP value. > > Message from sysl...@morgan at Apr 5 18:47:14 ... > kernel:CR2: > > > input: i2c IR (SAA713x remote) as /devices/virtual/input/input6 > ir-kbd-i2c: i2c IR (SAA713x remote) detected at i2c-1/1-0071/ir0 [cx18 i2c > driver #0-0] > ir-kbd-i2c: ir_poll_key > BUG: unable to handle kernel NULL pointer dereference at > IP: [<>] 0x0 > PGD 71c36067 PUD 2cca2067 PMD 0 > Oops: 0010 [1] SMP > CPU 0 > Modules linked in: ir_kbd_i2c(+) ir_common mxl5005s s5h1409 tuner_simple > tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common videodev > v4l1_compat v4l2_compat_ioctl32 tveeprom i2c_algo_bit fuse ipt_REJECT > nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp > nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables > cpufreq_ondemand powernow_k8 freq_table loop dm_multipath scsi_dh ipv6 > snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq > snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm i2c_piix4 snd_timer > snd_page_alloc ppdev parport_pc snd_hwdep i2c_core shpchp parport pcspkr snd > soundcore sr_mod r8169 mii k8temp hwmon cdrom sg floppy dm_snapshot dm_zero > dm_mirror dm_log dm_mod pata_acpi ata_generic pata_atiixp libata sd_mod > scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last > unloaded: tveeprom] > Pid: 9, comm: events/0 Not tainted 2.6.27.9-73.fc9.x86_64 #1 > RIP: 0010:[<>] [<>] 0x0 > RSP: 0018:880077bede58 EFLAGS: 00010286 > RAX: 001b RBX: 88005e73ee30 RCX: ccc6 > RDX: a031ba00 RSI: a031ba04 RDI: 88005e73ec00 > RBP: 880077bede80 R08: 880077bec000 R09: ccc6 > R10: 0126a7e22b3d R11: 880073159bd8 R12: 88005e73ec00 > R13: 0064 R14: a0318371 R15: 880077804908 > FS: 7fa0409126f0() GS:814ad100() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: CR3: 569f6000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process events/0 (pid: 9, threadinfo 880077bec000, task 880077bbdb80) > Stack: a03183df 880077bede80 88005e73ee38 880077804900 > 88005e73ee30 880077bedec0 8104fe45 880077bedec0 > 880077804900 880077804918 880077804908 880077beded0 > Call Trace: > [] ? ir_work+0x6e/0xd2 [ir_kbd_i2c] > [] run_workqueue+0xa3/0x146 > [] worker_thread+0xf5/0x109 > [] ? autoremove_wake_function+0x0/0x38 > [] ? worker_thread+0x0/0x109 > [] kthread+0x49/0x76 > [] child_rip+0xa/0x11 > [] ? restore_args+0x0/0x30 > [] ? kthread+0x0/0x76 > [] ? child_rip+0x0/0x11 > > > Code: Bad RIP value. > RIP [<>] 0x0 > RSP > CR2: > ---[ end trace 6076b08e85151d70 ]--- > > > That's because in ir-kbd-i2c.c:ir_poll_key(), ir->get_key() was a NULL > function pointer. > > I realized that ir-kbd-i2c.c:ir_probe() would need a fix-up for address > 0x71 for cx18 (and ivtv) or I would need to set the parameters via > struct IR_i2c_init_data. > > There's a usable get_key function for Hauppauge remotes in ir-kbd-i2c, > but no way via struct IR_i2c_init_data to specify that one wants to use > it from the bridge driver. Nor is there a way to set the RC5 ir_type > from the bridge driver. So mucking with ir-kbd-i2c.c for address 0x71 > is what I did next. Yeah, ir-kbd-i2c is messy, setup for some boards is done in the ir-kbd-i2c driver itself and for some other boards it is done in the bridge driver. I presume that the idea was to avoid code duplication on one hand and bloating ir-kbd-i2c with board-specific functions on the other
Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)
On Sun, 2009-04-05 at 16:40 +0200, Jean Delvare wrote: > Hi Mauro, > > On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: > > > > 3) So far, nobody gave us any positive return that the new IR model is > > working with > > any of the touched drivers. So, more tests are needed. I'm expecting to > > have a > > positive reply for each of the touched drivers. People, please test! > > Yes, please! :) Jean, I tested your original patch set so you can get some real feedback. The news is good, but I'll bore you with the details first. :) 1. My setup: HVR-1600: Hauppauge model 74041, rev C5B2, serial# 891351 has no radio, has IR receiver, has IR transmitter (Zilog Z8F0811) Hauppauge Remote: Grey top side & black bottom side; with 4 colored buttons Red, Green, Yellow, Blue; Numbers inside battery cover: A415-HPG M25909070211590 uname -a: Linux morgan.walls.org 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03 EST 2008 x86_64 x86_64 x86_64 GNU/Linux v4l-dvb: pulled this morning. 2. OK, my first test had no effect, because I'm an idiot. :) In the cx18 driver, I didn't remove the I2C addresses in your original patch, and I didn't add 0x71 as a valid address. 3. My second test had bad results: # modprobe ir-kbd-i2c debug=3 hauppauge=1 Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:Oops: 0010 [1] SMP Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:Code: Bad RIP value. Message from sysl...@morgan at Apr 5 18:47:14 ... kernel:CR2: input: i2c IR (SAA713x remote) as /devices/virtual/input/input6 ir-kbd-i2c: i2c IR (SAA713x remote) detected at i2c-1/1-0071/ir0 [cx18 i2c driver #0-0] ir-kbd-i2c: ir_poll_key BUG: unable to handle kernel NULL pointer dereference at IP: [<>] 0x0 PGD 71c36067 PUD 2cca2067 PMD 0 Oops: 0010 [1] SMP CPU 0 Modules linked in: ir_kbd_i2c(+) ir_common mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 tveeprom i2c_algo_bit fuse ipt_REJECT nf_conntrack_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand powernow_k8 freq_table loop dm_multipath scsi_dh ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm i2c_piix4 snd_timer snd_page_alloc ppdev parport_pc snd_hwdep i2c_core shpchp parport pcspkr snd soundcore sr_mod r8169 mii k8temp hwmon cdrom sg floppy dm_snapshot dm_zero dm_mirror dm_log dm_mod pata_acpi ata_generic pata_atiixp libata sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: tveeprom] Pid: 9, comm: events/0 Not tainted 2.6.27.9-73.fc9.x86_64 #1 RIP: 0010:[<>] [<>] 0x0 RSP: 0018:880077bede58 EFLAGS: 00010286 RAX: 001b RBX: 88005e73ee30 RCX: ccc6 RDX: a031ba00 RSI: a031ba04 RDI: 88005e73ec00 RBP: 880077bede80 R08: 880077bec000 R09: ccc6 R10: 0126a7e22b3d R11: 880073159bd8 R12: 88005e73ec00 R13: 0064 R14: a0318371 R15: 880077804908 FS: 7fa0409126f0() GS:814ad100() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: CR3: 569f6000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process events/0 (pid: 9, threadinfo 880077bec000, task 880077bbdb80) Stack: a03183df 880077bede80 88005e73ee38 880077804900 88005e73ee30 880077bedec0 8104fe45 880077bedec0 880077804900 880077804918 880077804908 880077beded0 Call Trace: [] ? ir_work+0x6e/0xd2 [ir_kbd_i2c] [] run_workqueue+0xa3/0x146 [] worker_thread+0xf5/0x109 [] ? autoremove_wake_function+0x0/0x38 [] ? worker_thread+0x0/0x109 [] kthread+0x49/0x76 [] child_rip+0xa/0x11 [] ? restore_args+0x0/0x30 [] ? kthread+0x0/0x76 [] ? child_rip+0x0/0x11 Code: Bad RIP value. RIP [<>] 0x0 RSP CR2: ---[ end trace 6076b08e85151d70 ]--- That's because in ir-kbd-i2c.c:ir_poll_key(), ir->get_key() was a NULL function pointer. I realized that ir-kbd-i2c.c:ir_probe() would need a fix-up for address 0x71 for cx18 (and ivtv) or I would need to set the parameters via struct IR_i2c_init_data. There's a usable get_key function for Hauppauge remotes in ir-kbd-i2c, but no way via struct IR_i2c_init_data to specify that one wants to use it from the bridge driver. Nor is there a way to set the RC5 ir_type from the bridge driver. So mucking with ir-kbd-i2c.c for address 0x71 is what I did next. 4. For my third test I modified a few lines in ir-kbd-i2c:ir_probe.c: ... case 0x7a: case 0x47: case 0x71:
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
On Sun, 5 Apr 2009, Jean Delvare wrote: > Hi Mauro, > > On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: > > From the discussions we already have, I noticed some points to take care of: > > > > 1) about the lirc support, I don't think we should change a kernel driver > > due > > to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, > > we > > need to better address this with lirc developers; > > Well, the new binding model makes it harder for "rogue" drivers such as > lirc_i2c. They will need _some_ form of cooperation from us, which will > most likely come when they get merged into the kernel tree. > > > 2) the way Mike is proposing to solve the issue with pvrusb2 will break > > userspace usage for people that have those devices whose IR work with the > > in-kernel IR i2c driver. This means that we'll cause a kernel regression > > due to > > an out-of-tree driver; It's an either/or. If nothing is done, the ir-kbd-i2c become unusable for pvrusb2 but lirc (for now) continues to work. If Jean's change is accepted as-is, then ir-kbd-i2c will be ok but now lirc is toast. If I implement what I am suggesting, then it becomes possible at least for both cases to still work, but with a module option. Not perfect, but it is the only way I see to allow this situation to retain some sanity. In the longer term, the lirc folks are going to have to change what they are doing. Fine, that's a problem they have to solve. It's nothing I can do anyting about. But I am not going to be the instigator that breaks lirc as used by the pvrusb2 driver. In the short term, implementing the module option breaks the deadlock here. Jean can continue getting rid of the old i2c model and I won't be a pain about it. > > > > 3) So far, nobody gave us any positive return that the new IR model is > > working with > > any of the touched drivers. So, more tests are needed. I'm expecting to > > have a > > positive reply for each of the touched drivers. People, please test! > > Yes, please! :) > > > Since the merge window is almost finished, IMO, we should postpone those > > changes to 2.6.31, (...) > > The legacy i2c model will be gone in 2.6.30. Really. Hans and myself > have put enough energy into this to not let it slip for just a > miserable infrared support module which I understand is hardly used by > anyone. > > So it's really up to you, either you accept my ir-kbd-i2c conversion > "now" (that is, when it has received the minimum testing and reviewing > it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you > don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build > failures. Accept his ir-kbd-i2c conversion now, minus the pvrusb2 changes. I will deal with the pvrusb2 driver appropriately (and immediately). That should resolve the issue for the short term. > > > to better address the lirc issue and to give people more > > time for testing, applying the changesets after the end of the merge window > > at > > the v4l/dvb development tree. This will help people to test, review and > > propose > > changes if needed. > > These changes are on-going for over a year now. If the lirc people > didn't hear about it so far, I doubt they will pay more attention just > because we delay the deadline by 2 months. The only thing that will get > their attention is when lirc_i2c break. So let's just do that ;) > > Don't get me wrong. I don't want to be (too) rude to lirc developers. > If they need help to port their code to the new i2c binding model, I'll > help them. If they need help to merge lirc_i2c into the kernel, I'll > help as well. But I don't see any point in delaying important, long > awaited kernel changes just for them. As long as they are out-of-tree, > they can fix things after the fact easily. They aren't affected by the > merge window. They'll have several weeks before kernel 2.6.30 is > actually released, which they can use to fix anything that broke. > I agree. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
Hi Mauro, On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote: > From the discussions we already have, I noticed some points to take care of: > > 1) about the lirc support, I don't think we should change a kernel driver due > to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we > need to better address this with lirc developers; Well, the new binding model makes it harder for "rogue" drivers such as lirc_i2c. They will need _some_ form of cooperation from us, which will most likely come when they get merged into the kernel tree. > 2) the way Mike is proposing to solve the issue with pvrusb2 will break > userspace usage for people that have those devices whose IR work with the > in-kernel IR i2c driver. This means that we'll cause a kernel regression due > to > an out-of-tree driver; > > 3) So far, nobody gave us any positive return that the new IR model is > working with > any of the touched drivers. So, more tests are needed. I'm expecting to have a > positive reply for each of the touched drivers. People, please test! Yes, please! :) > Since the merge window is almost finished, IMO, we should postpone those > changes to 2.6.31, (...) The legacy i2c model will be gone in 2.6.30. Really. Hans and myself have put enough energy into this to not let it slip for just a miserable infrared support module which I understand is hardly used by anyone. So it's really up to you, either you accept my ir-kbd-i2c conversion "now" (that is, when it has received the minimum testing and reviewing it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build failures. > to better address the lirc issue and to give people more > time for testing, applying the changesets after the end of the merge window at > the v4l/dvb development tree. This will help people to test, review and > propose > changes if needed. These changes are on-going for over a year now. If the lirc people didn't hear about it so far, I doubt they will pay more attention just because we delay the deadline by 2 months. The only thing that will get their attention is when lirc_i2c break. So let's just do that ;) Don't get me wrong. I don't want to be (too) rude to lirc developers. If they need help to port their code to the new i2c binding model, I'll help them. If they need help to merge lirc_i2c into the kernel, I'll help as well. But I don't see any point in delaying important, long awaited kernel changes just for them. As long as they are out-of-tree, they can fix things after the fact easily. They aren't affected by the merge window. They'll have several weeks before kernel 2.6.30 is actually released, which they can use to fix anything that broke. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
On Sat, 4 Apr 2009 14:24:27 +0200 Jean Delvare wrote: > Hi all, > > Here finally comes my conversion of ir-kbd-i2c to the new i2c binding > model. I've split it into 6 pieces for easier review. Firstly there are > 2 preliminary patches: > > media-video-01-cx18-fix-i2c-error-handling.patch > media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch > > Then 2 patches doing the actual conversion: > > media-video-03-ir-kbd-i2c-convert-to-new-style.patch > media-video-04-configure-ir-receiver.patch > > And lastly 2 patches cleaning up saa7134-input thanks to the new > possibilities offered by the conversion: > > media-video-05-saa7134-input-cleanup-msi-ir.patch > media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch > > This patch set is against the v4l-dvb repository, but I didn't pay > attention to the compatibility issues. I simply build-tested it on > 2.6.27 and 2.6.29. > > This patch set touches many different drivers and I can't test any of > them. My only TV card with an IR receiver doesn't make use of > ir-kbd-i2c. So I would warmly welcome testers. The more testing my > changes can get, the better. > > And of course I welcome reviews and comments as well. I had to touch > many drivers I don't know anything about so it is possible that I > missed something. > > I'll post all 6 patches as replies to this post. They can also be > temporarily downloaded from: > http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ > Additionally I've put a combined patch there, to make testing easier: > > http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch > But for review the individual patches are much better. > > Thanks, >From the discussions we already have, I noticed some points to take care of: 1) about the lirc support, I don't think we should change a kernel driver due to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we need to better address this with lirc developers; 2) the way Mike is proposing to solve the issue with pvrusb2 will break userspace usage for people that have those devices whose IR work with the in-kernel IR i2c driver. This means that we'll cause a kernel regression due to an out-of-tree driver; 3) So far, nobody gave us any positive return that the new IR model is working with any of the touched drivers. So, more tests are needed. I'm expecting to have a positive reply for each of the touched drivers. People, please test! Since the merge window is almost finished, IMO, we should postpone those changes to 2.6.31, to better address the lirc issue and to give people more time for testing, applying the changesets after the end of the merge window at the v4l/dvb development tree. This will help people to test, review and propose changes if needed. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
Jean: I understand what you're trying to do but how is LIRC expected to still work if all drivers now force the user over to ir-kbd? -Mike On Sat, 4 Apr 2009, Jean Delvare wrote: > Hi all, > > Here finally comes my conversion of ir-kbd-i2c to the new i2c binding > model. I've split it into 6 pieces for easier review. Firstly there are > 2 preliminary patches: > > media-video-01-cx18-fix-i2c-error-handling.patch > media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch > > Then 2 patches doing the actual conversion: > > media-video-03-ir-kbd-i2c-convert-to-new-style.patch > media-video-04-configure-ir-receiver.patch > > And lastly 2 patches cleaning up saa7134-input thanks to the new > possibilities offered by the conversion: > > media-video-05-saa7134-input-cleanup-msi-ir.patch > media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch > > This patch set is against the v4l-dvb repository, but I didn't pay > attention to the compatibility issues. I simply build-tested it on > 2.6.27 and 2.6.29. > > This patch set touches many different drivers and I can't test any of > them. My only TV card with an IR receiver doesn't make use of > ir-kbd-i2c. So I would warmly welcome testers. The more testing my > changes can get, the better. > > And of course I welcome reviews and comments as well. I had to touch > many drivers I don't know anything about so it is possible that I > missed something. > > I'll post all 6 patches as replies to this post. They can also be > temporarily downloaded from: > http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ > Additionally I've put a combined patch there, to make testing easier: > > http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch > But for review the individual patches are much better. > > Thanks, > -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model
Hi all, Here finally comes my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 6 pieces for easier review. Firstly there are 2 preliminary patches: media-video-01-cx18-fix-i2c-error-handling.patch media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch Then 2 patches doing the actual conversion: media-video-03-ir-kbd-i2c-convert-to-new-style.patch media-video-04-configure-ir-receiver.patch And lastly 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: media-video-05-saa7134-input-cleanup-msi-ir.patch media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27 and 2.6.29. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. I'll post all 6 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
