Re: [RFC] Anticipating lirc breakage
On Mon, 6 Apr 2009, Jean Delvare wrote: Hi all, In the light of recent discussions and planed changes to the i2c subsystem and the ir-kbd-i2c driver, I will try to summarize the situation and make some proposals. Note that I am really not sure what we want to do, so this is a true request for opinions. First of all, the original reason for these changes is that I want to get rid of the legacy i2c binding model. As far as IR support is concerned, this means two things: * The ir-kbd-i2c driver must be converted to the new i2c binding model. I have been working on this already. * The removal of the legacy model will break lirc_i2c and possibly other lirc drivers. These will have to be converted to the new i2c binding model as well. While discussing my changes to ir-kbd-i2c, I received objections that these would adversely affect lirc users, and proposals were made to work around this problem, either by the means of module parameters, or by adding per-card logic in the bridge drivers. While this temporarily addresses the conflict with lirc, I feel like it is wasted energy because the second point is much more critical for lirc users. I'm going to remove the legacy i2c model pretty soon now and lirc_i2c and friends will have to be updated. This means two things: It wasn't really wasting that much energy for me. The change was simple and now that you made me look at this issue more closely, I realize I need to do something more serious in the pvrusb2 driver anyway to enable better control over which IR receiver(s) are to be enabled when the user has multiple devices. So in the end for me at least, it wasn't a waste. * There is no point in refining the ir-kbd-i2c conversion for users of the current lirc drivers, because the removal of the legacy i2c model will break these drivers a lot more anyway. * We need to come up with a strategy that makes it possible for lirc modules to still work afterwards. This is not trivial because the new i2c binding model makes life much harder for rogue/out-of-tree i2c drivers (note, this is just a side effect, the new model was not designed with this in mind.) The main technical problems I see as far as converting lirc to the new i2c binding model is concerned are: * Going the .detect() route is not as flexible as it was beforehand. In particular, having per-board probed address lists is no longer possible. It is possible to filter the addresses on a per-board basis after the fact, but the probes will still be issued for all addresses. I seem to remember that probing random addresses did cause trouble in the past on some boards, so I doubt we want to go that route. This is the reason why I decided to NOT go the .detect() route for ir-kbd-i2c conversion. * If we don't use .detect(), the bridge drivers must instantiate the devices themselves. That's what my ir-kbd-i2c patches do. One requirement is then that the bridge drivers and the chip drivers agree on the i2c device name(s). This was true for ir-kbd-i2c, it is true for lirc as well. Where it becomes difficult is that lirc lives outside of the kernel, while bridge drivers live inside the kernel. This will make the changes more difficult to synchronize. Probably a good incentive for lirc developers to merge their drivers into the kernel tree. While I think we all agree that lirc drivers should be merged in the kernel tree, it is pretty clear that it won't happen tomorrow. And, more importantly, it won't happen before I get rid of the legacy i2c binding model. So we need to come up with a design which makes it possible to keep using out-of-tree lirc drivers. It doesn't need to be perfect, but it has to somewhat work for now. Yup. Totally agree. My initial proposal made bridge drivers create ir-kbd [1] I2C devices for the ir-kbd-i2c driver to use. Mike Isely changed this in the pvrusb2 bridge driver to only instantiate the devices for boards on which ir-kbd-i2c is known to work. While this makes sense for the current situation (lirc_i2c is a legacy i2c driver) it will break as soon as lirc_i2c is converted to a new-style i2c driver: the converted lirc_i2c driver will need I2C devices to bind to, and the pvrusb2 driver won't create them. Right, because we haven't addressed the question of still making possible the choice of which actual driver to load. The change I proposed and implemented (within the pvrusb2 driver) was just a simple low-risk attempt to allow for the status quo to still be possible within the pvrusb2 driver. That will work for _right this moment_, but once you've removed the legacy i2c binding mechanism, there's no longer any status quo to maintain. Same goes for cx18 boards, as Andy Walls and myself agreed to not create I2C devices for the IR receivers, because we know that ir-kbd-i2c doesn't support them. This made sense for the current situation, but the lirc_i2c
Re: USB DVB unplug: kernel BUG at kernel/module.c:912!
On Tue, 31 Mar 2009 14:28:45 +0200 (CEST) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: When unplugging a Sony PlayTV USB DVB adaptor from a PS3, I get | kernel BUG at kernel/module.c:912! on 2.6.29-06608-g15f7176. Insert Sony PlayTV USB: Mar 31 13:41:57 ps3 kernel: [ 266.556878] usb 1-2.1: new high speed USB device using ps3-ehci-driver and address 6 Mar 31 13:41:57 ps3 kernel: [ 266.649435] usb 1-2.1: New USB device found, idVendor=1415, idProduct=0003 Mar 31 13:41:57 ps3 kernel: [ 266.649448] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 31 13:41:57 ps3 kernel: [ 266.649457] usb 1-2.1: Product: SCEH-0036 Mar 31 13:41:57 ps3 kernel: [ 266.649464] usb 1-2.1: Manufacturer: SONY Mar 31 13:41:57 ps3 kernel: [ 266.649475] usb 1-2.1: SerialNumber: ALR001GLZS Mar 31 13:41:57 ps3 kernel: [ 266.649819] usb 1-2.1: configuration #1 chosen from 1 choice Mar 31 13:41:58 ps3 kernel: [ 267.496197] dib0700: loaded with support for 9 different device-types Mar 31 13:41:58 ps3 kernel: [ 267.497162] dvb-usb: found a 'Sony PlayTV' in cold state, will try to load a firmware Mar 31 13:41:58 ps3 kernel: [ 267.497182] usb 1-2.1: firmware: requesting dvb-usb-dib0700-1.20.fw Mar 31 13:41:58 ps3 kernel: [ 267.547717] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Mar 31 13:41:58 ps3 kernel: [ 267.760597] dib0700: firmware started successfully. Mar 31 13:41:59 ps3 kernel: [ 268.264509] dvb-usb: found a 'Sony PlayTV' in warm state. Mar 31 13:41:59 ps3 kernel: [ 268.264696] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Mar 31 13:41:59 ps3 kernel: [ 268.265293] DVB: registering new adapter (Sony PlayTV) Mar 31 13:41:59 ps3 kernel: [ 268.502455] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... Mar 31 13:41:59 ps3 kernel: [ 268.685103] DiB0070: successfully identified Mar 31 13:41:59 ps3 kernel: [ 268.685117] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Mar 31 13:41:59 ps3 kernel: [ 268.685539] DVB: registering new adapter (Sony PlayTV) Mar 31 13:41:59 ps3 kernel: [ 268.842648] DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)... Mar 31 13:42:00 ps3 kernel: [ 269.029071] DiB0070: successfully identified Mar 31 13:42:00 ps3 kernel: [ 269.029331] input: IR-receiver inside an USB DVB receiver as /class/input/input3 Mar 31 13:42:00 ps3 kernel: [ 269.052670] dvb-usb: schedule remote query interval to 50 msecs. Mar 31 13:42:00 ps3 kernel: [ 269.052685] dvb-usb: Sony PlayTV successfully initialized and connected. Mar 31 13:42:00 ps3 kernel: [ 269.052917] usbcore: registered new interface driver dvb_usb_dib0700 Unplug Sony PlayTV USB: Mar 31 14:01:28 ps3 kernel: [ 1437.101593] usb 1-2.1: USB disconnect, address 6 Mar 31 14:01:28 ps3 kernel: [ 1437.133461] [ cut here ] Mar 31 14:01:28 ps3 kernel: [ 1437.137955] kernel BUG at kernel/module.c:912! Mar 31 14:01:28 ps3 kernel: [ 1437.142408] Oops: Exception in kernel mode, sig: 5 [#1] Mar 31 14:01:28 ps3 kernel: [ 1437.146533] SMP NR_CPUS=2 PS3 Mar 31 14:01:28 ps3 kernel: [ 1437.150560] Modules linked in: dvb_usb_dib0700 dib7000p dib3000mc dvb_usb dvb_core dib7000m dibx000_common dib0070 i2c_core nfsd exportfs dm_crypt dm_mod sg ps3disk ps3rom ps3flash ps3stor_lib ps3vram joydev evdev Mar 31 14:01:28 ps3 kernel: [ 1437.155317] NIP: c008ae54 LR: c008ae4c CTR: c008ae20 Mar 31 14:01:28 ps3 kernel: [ 1437.159706] REGS: c6987410 TRAP: 0700 Tainted: GW (2.6.29-06608-g15f7176) Mar 31 14:01:28 ps3 kernel: [ 1437.164144] MSR: 80028032 EE,CE,IR,DR CR: 44004042 XER: 2000 Mar 31 14:01:28 ps3 kernel: [ 1437.168636] TASK = c69811c0[111] 'khubd' THREAD: c6984000 CPU: 0 Mar 31 14:01:28 ps3 kernel: [ 1437.168853] GPR00: c05777f8 c6987690 c0639b20 Mar 31 14:01:28 ps3 kernel: [ 1437.173362] GPR04: c00d1504 d29ced10 c065dc68 Mar 31 14:01:28 ps3 kernel: [ 1437.177894] GPR08: c05777f8 d28092f8 c05777f8 Mar 31 14:01:28 ps3 kernel: [ 1437.182439] GPR12: d29d53f0 c0664200 00e9 c6d71830 Mar 31 14:01:28 ps3 kernel: [ 1437.186985] GPR16: 03e8 c6de9400 c6d71830 Mar 31 14:01:28 ps3 kernel: [ 1437.191559] GPR20: c6cc6000 c6cc6000 Mar 31 14:01:28 ps3 kernel: [ 1437.196120] GPR24: 0001 c6cc63a0 c6bf90e8 c122c800 Mar 31 14:01:28 ps3 kernel: [ 1437.200676] GPR28: 0001 c312a000 d2b5c080 d28092f8 Mar 31 14:01:28 ps3 kernel: [ 1437.209542] NIP [c008ae54] .symbol_put_addr+0x34/0x64 Mar 31 14:01:28 ps3
Re: [PATCH] Add ov9655 camera driver
aderach schrieb: Does this driver is working for ov534 with 9657 sensor ID ? I don't know the ov534. The sensor ID is the same. At the moment the driver support only the YUV formats. I don't know, which format the ov534 expect. Where did you find the document to write this code? I haven't a real documentation. I get the preliminary OV9655 datasheet with the register description from OmniVision. Most of the register values in the driver were extracted from the inf file of the evaluation board driver. I compare the values for the different output sizes and analyze them. Based on this and some test I write the driver. Regards Stefan Message initial *De*: Guennadi Liakhovetski g.liakhovet...@gmx.de mailto:guennadi%20liakhovetski%20%3cg.liakhovet...@gmx.de%3e *À*: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de mailto:stefan%20herbrechtsmeier%20%3chbme...@hni.uni-paderborn.de%3e *Cc*: Linux Media Mailing List linux-media@vger.kernel.org mailto:linux%20media%20mailing%20list%20%3clinux-me...@vger.kernel.org%3e, Hans Verkuil hverk...@xs4all.nl mailto:hans%20verkuil%20%3chverk...@xs4all.nl%3e *Sujet*: Re: [PATCH] Add ov9655 camera driver *Date*: Mon, 6 Apr 2009 17:58:57 +0200 (CEST) On Mon, 6 Apr 2009, Stefan Herbrechtsmeier wrote: Add a driver for the OmniVision ov9655 camera sensor. The driver use the soc_camera framework. It was tested on the BeBot robot with a PXA270 processor. Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de mailto:hbme...@hni.uni-paderborn.de Hans, does it make sense to include this one or shall we wait for gspca on this one too? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ for: changeset: 11423:89ed21b68f44 gspca - t613: Do sensor reset only for sensor om6802. changeset: 11424:76a9121958e1 gspca - mr97310a: Return good error code in mod_init. changeset: 11425:167e34fc7c99 gspca - main: Use usb interface as parent. changeset: 11426:b9d34b2862da gspca - zc3xx: Bad probe of many webcams since adcm2700 addition. changeset: 11427:2962ff4ab10f gspca - m5602-mt9m111: Convert the mt9m111 to use a v4l2 ctrl cache changeset: 11428:52c95bb0d050 gspca - m5602-s5k83a: Add rotation, ctrl cache. Rename some ctrls. changeset: 11429:82f6bfcbb270 gspca - m5602-po1030: Convert to have a v4l2 ctrl cache changeset: 11430:3f9fc876da03 gspca - m5602-s5k4aa: Convert to use the v4l2 ctrl cache changeset: 11431:e1c71183b773 gspca - m5602-mt9m111: Remove the unused power_down struct member changeset: 11432:86e200613a64 gspca - m5602-ov9650: Improve the vflip quirk handling. changeset: 11433:22def28d4121 gspca - m5602-po1030: Rename register defines, add missing ones. changeset: 11434:415aca582f87 gspca - m5602-po1030: Simplify register defines changeset: 11435:35829089cfbc gspca - m5602-po1030: Set all v4l2 controls at sensor init changeset: 11436:dba0356a9afc gspca - m5602-po1030: Add auto white balancing control changeset: 11437:6732855e2f34 gspca - m5602-po1030: Remove unnecessary error check changeset: 11438:572d059c7923 gspca - m5602-po1030: Probe read only register at probe time changeset: 11439:139f4c219762 gspca - m5602-po1030: Split up the init into init and start changeset: 11440:6a48dfe848d0 gspca - m5602-po1030: Remove unneeded init sequences changeset: 11441:1c7f4d480ce1 gspca - m5602-mt9m111: Set the cached v4l2 ctrl values changeset: 11442:16029093f604 gspca - m5602-s5k4aa: Set all v4l2 ctrls on sensor init. changeset: 11443:dfc66c5b9a94 gspca - m5602: Let all ctrls on all sensors be static changeset: 11444:9d589114fbfd gspca - m5602: Move all dump_sensor to the init function changeset: 11445:bbc36950cdab gspca - m5602-mt9m111: Remove redundant init sequences changeset: 11446:e32daed9f3b1 gspca - m5602-mt9m111: More redundant init cleanup changeset: 11447:267615fea4b3 gspca - m5602-mt9m111: Implement an auto white balancing control changeset: 11448:fd5a12cf094f gspca - m5602-mt9m111: Remove more redundant init changeset: 11449:743a9416b896 gspca - m5602-mt9m111: Remove lots of redundant init code changeset: 11450:8df13edfaa7d gspca - m5602-po1030: Release reset when init is done. changeset: 11451:ef21e760a731 gspca - m5602-po1030: Fix sensor probing. changeset: 11452:3f480f9375e3 gspca - m5602-po1030: Lower the default blue and gain balance changeset: 11453:848a0681e66a gspca - m5602: Add some more register defines changeset: 11454:aed40a914a7c gspca - m5602-po1030: Set the blue balance in the init not red balance twice changeset: 11455:061ee364cbbd gspca - m5602-mt9m111: Replace various magic constants with defines changeset: 11456:0b1998e76cb8 gspca - m5602-mt9m111: More magic constants replacement changeset: 11457:717e661628d1 gspca - m5602-mt9m111: Remove lots of redundant sensor reads changeset: 11458:2d4c41cc9b6e gspca - m5602-mt9m111: More constant replacement changeset: 11459:3055659c9940 gspca - m5602-mt9m111: Remove lots of redundant init code changeset: 11460:b0d269f96d1d gspca - mr97310a: Webcam 093a:010f added. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: USB DVB unplug: kernel BUG at kernel/module.c:912!
On Mon, 6 Apr 2009, Andrew Morton wrote: On Tue, 31 Mar 2009 14:28:45 +0200 (CEST) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: When unplugging a Sony PlayTV USB DVB adaptor from a PS3, I get | kernel BUG at kernel/module.c:912! on 2.6.29-06608-g15f7176. Unplug Sony PlayTV USB: Mar 31 14:01:28 ps3 kernel: [ 1437.101593] usb 1-2.1: USB disconnect, address 6 Mar 31 14:01:28 ps3 kernel: [ 1437.133461] [ cut here ] Mar 31 14:01:28 ps3 kernel: [ 1437.137955] kernel BUG at kernel/module.c:912! Mar 31 14:01:28 ps3 kernel: [ 1437.142408] Oops: Exception in kernel mode, sig: 5 [#1] Mar 31 14:01:28 ps3 kernel: [ 1437.146533] SMP NR_CPUS=2 PS3 Mar 31 14:01:28 ps3 kernel: [ 1437.150560] Modules linked in: dvb_usb_dib0700 dib7000p dib3000mc dvb_usb dvb_core dib7000m dibx000_common dib0070 i2c_core nfsd exportfs dm_crypt dm_mod sg ps3disk ps3rom ps3flash ps3stor_lib ps3vram joydev evdev Mar 31 14:01:28 ps3 kernel: [ 1437.155317] NIP: c008ae54 LR: c008ae4c CTR: c008ae20 Mar 31 14:01:28 ps3 kernel: [ 1437.159706] REGS: c6987410 TRAP: 0700 Tainted: GW (2.6.29-06608-g15f7176) Mar 31 14:01:28 ps3 kernel: [ 1437.164144] MSR: 80028032 EE,CE,IR,DR CR: 44004042 XER: 2000 Mar 31 14:01:28 ps3 kernel: [ 1437.168636] TASK = c69811c0[111] 'khubd' THREAD: c6984000 CPU: 0 Mar 31 14:01:28 ps3 kernel: [ 1437.168853] GPR00: c05777f8 c6987690 c0639b20 Mar 31 14:01:28 ps3 kernel: [ 1437.173362] GPR04: c00d1504 d29ced10 c065dc68 Mar 31 14:01:28 ps3 kernel: [ 1437.177894] GPR08: c05777f8 d28092f8 c05777f8 Mar 31 14:01:28 ps3 kernel: [ 1437.182439] GPR12: d29d53f0 c0664200 00e9 c6d71830 Mar 31 14:01:28 ps3 kernel: [ 1437.186985] GPR16: 03e8 c6de9400 c6d71830 Mar 31 14:01:28 ps3 kernel: [ 1437.191559] GPR20: c6cc6000 c6cc6000 Mar 31 14:01:28 ps3 kernel: [ 1437.196120] GPR24: 0001 c6cc63a0 c6bf90e8 c122c800 Mar 31 14:01:28 ps3 kernel: [ 1437.200676] GPR28: 0001 c312a000 d2b5c080 d28092f8 Mar 31 14:01:28 ps3 kernel: [ 1437.209542] NIP [c008ae54] .symbol_put_addr+0x34/0x64 Mar 31 14:01:28 ps3 kernel: [ 1437.214040] LR [c008ae4c] .symbol_put_addr+0x2c/0x64 Mar 31 14:01:28 ps3 kernel: [ 1437.218494] Call Trace: Mar 31 14:01:28 ps3 kernel: [ 1437.222885] [c6987690] [0001] 0x1 (unreliable) Mar 31 14:01:28 ps3 kernel: [ 1437.227447] [c6987710] [d29ce2e0] .dvb_frontend_detach+0x80/0x10c [dvb_core] Mar 31 14:01:28 ps3 kernel: [ 1437.232018] [c69877a0] [d2b4f088] .dvb_usb_adapter_frontend_exit+0x30/0x4c [dvb_usb] Mar 31 14:01:28 ps3 kernel: [ 1437.236598] [c6987820] [d2b4e4ec] .dvb_usb_exit+0x3c/0xf0 [dvb_usb] Mar 31 14:01:28 ps3 kernel: [ 1437.241189] [c69878c0] [d2b4e5ec] .dvb_usb_device_exit+0x4c/0x74 [dvb_usb] Mar 31 14:01:28 ps3 kernel: [ 1437.245784] [c6987940] [c0279ca0] .usb_unbind_interface+0x7c/0x138 Mar 31 14:01:28 ps3 kernel: [ 1437.250348] [c69879e0] [c02430e8] .__device_release_driver+0xb8/0x100 Mar 31 14:01:28 ps3 kernel: [ 1437.254936] [c6987a70] [c024325c] .device_release_driver+0x30/0x54 Mar 31 14:01:28 ps3 kernel: [ 1437.259518] [c6987b00] [c02423a4] .bus_remove_device+0xe4/0x124 Mar 31 14:01:28 ps3 kernel: [ 1437.264104] [c6987b90] [c023ff98] .device_del+0x178/0x1f8 Mar 31 14:01:28 ps3 kernel: [ 1437.268631] [c6987c20] [c0276eb4] .usb_disable_device+0xb0/0x168 Mar 31 14:01:28 ps3 kernel: [ 1437.273175] [c6987cc0] [c0271630] .usb_disconnect+0xc0/0x158 Mar 31 14:01:28 ps3 kernel: [ 1437.277606] [c6987d70] [c027260c] .hub_thread+0x538/0xf14 Mar 31 14:01:28 ps3 kernel: [ 1437.281894] [c6987f00] [c006c298] .kthread+0x78/0xc4 Mar 31 14:01:28 ps3 kernel: [ 1437.286192] [c6987f90] [c00209e8] .kernel_thread+0x54/0x70 Mar 31 14:01:28 ps3 kernel: [ 1437.290510] Instruction dump: Mar 31 14:01:28 ps3 kernel: [ 1437.294762] 7c0802a6 f8010010 7c7f1b78 f821ff81 4bfde4fd 6000 2fa3 409e0030 Mar 31 14:01:28 ps3 kernel: [ 1437.299233] 7fe3fb78 4bffc3b9 2fa3 409e000c 0fe0 4800 38210080 e8010010 Mar 31 14:01:28 ps3 kernel: [ 1437.304457] ---[ end trace d1da44b3213415b8 ]--- Is it a post-2.6.29 regression? The support for Sony PlayTV was added to the dib0700 driver after 2.6.29. But it also happened with another DVB-T USB
Re: [RFC] Anticipating lirc breakage
Hi Andy, On Mon, 06 Apr 2009 21:20:37 -0400, Andy Walls wrote: On Mon, 2009-04-06 at 17:44 +0200, Jean Delvare wrote: The bottom line is that we have to instantiate I2C devices for IR components regardless of the driver which will handle them (ir-kbd-i2c, lirc_i2c or another one). I can think of two different strategies here: 1* Instantiate driver-neutral I2C devices, named for example ir_video. Let both ir-kbd-i2c and lirc_i2c (and possibly others) bind to them. The first loaded driver gets to bind to the device. This isn't so different from the current situation, the only difference being that the choice of addresses to probe is moved to the bridge drivers. We can even go with separate names for some devices (for example ir_zilog), as each I2C driver can list which devices it supports. 2* Let the bridge drivers decide whether ir-kbd-i2c or lirc_i2c should drive any given device, by instantiating I2C devices with different names, for example ir_kbd for ir-kbd-i2c and lirc for lirc_i2c. This might give better out-of-the-box results for some devices and would make it possible to let the device drivers auto-load. There's a problem though for IR devices which are supported by both ir-kbd-i2c and lirc_i2c: not every user installs lirc, so it's not clear what devices should be created. We could default to ir_kbd and switch to lirc using a module parameter, as Mike Isely proposed for pvrusb2. I have a clear preference for the first strategy. I feel that creating devices for a specific driver is the wrong way to go, as we will certainly want to merge ir-kbd-i2c and lirc_i2c into a single driver in the future. However, I am not familiar enough with IR receivers to know for sure if the first strategy will work. I would welcome comments on this. Does anyone see a problem with strategy #1? Does anyone see notable advantages in strategy #2? I have a preference for #1. Strategy #1 gives flexibility and control for *every* user. Strategy #2 has better turn-key operation for *most* users. Note that strategy #1 is also what we have at the moment, incidentally. If we go with strategy #1 then my original patch set is probably very similar to the solution. The only differences would be the name of the I2C devices being created (ir_video instead of ir-kbd) and the list of addresses being probed (we'd need to add the addresses lirc_i2c supports but ir-kbd-i2c does not.) May I ask, why the virtual chip names like ir_video? Almost every I2C IR chip should have a unique part number on it. Maybe just use the name of the chip as - well - the name of the I2C chip at the address: KS003, Z8F0811, PIC64xx, CX2584x IR, etc. That way it is almost unambiguous what the IR chip part is at the I2C address, and also what the IR chip driver module needs to support. I suppose this is a bit problematic for micrcontroller chips with different controller code images, but slight additions to the name can take care of that: Z8F0811 Hauppauge, Z8F0811 Acme. +-- ficticious company It seems obvious to me. (So there must be something wrong with it. ;] ) No, in theory you are perfectly right, it would be much better to name devices by their actual name. I decided to go with a virtual name merely because of the current structure of the ir-kbd-i2c code. I wanted to make the conversion as direct as possible. But in the future, adding separate names for specific IR devices would be nice. As you found out though, this becomes a little bit more complex when the IR device in question is a generic micro-controller. Not only the same chip can be used differently as different IR devices, but virtually the same chip can also be used somewhere else in the kernel for completely different function. In this case I think it is better to either suffix the I2C device name to distinguish between implementations, or go with a plain virtual name right ahead. Keep in mind that we are relatively free as to what I2C device names we use. All that matters is uniqueness and relevance. And to stick to the convention to use only lowercase letters, digits and underscores in the names. -- 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/3] FM Transmitter driver
Hello again, On Fri, Apr 03, 2009 at 01:48:21PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: On Fri, Apr 03, 2009 at 01:29:27PM +0200, ext Hans Verkuil wrote: On Friday 03 April 2009 12:48:19 Eduardo Valentin wrote: Hi, On Fri, Apr 03, 2009 at 12:36:53PM +0200, ext Hans Verkuil wrote: On Friday 03 April 2009 12:12:30 Eduardo Valentin wrote: On Thu, Apr 02, 2009 at 06:36:37PM +0200, ext Hans Verkuil wrote: On Thursday 02 April 2009 14:02:11 Eduardo Valentin wrote: Hi Hans, On Thu, Apr 02, 2009 at 09:47:11AM +0200, ext Hans Verkuil wrote: On Wednesday 01 April 2009 11:43:28 Eduardo Valentin wrote: Hello Mauro and v4l guys, This series contains a v4l2 radio driver which adds support for Silabs si4713 devices. That is a FM transmitter device. As you should know, v4l2 does not contain representation of FM Transmitters (at least that I know). So this driver was written highly based on FM receivers API, which can cover most of basic functionality. However, as expected, there are some properties which were not covered. For those properties, sysfs nodes were added in order to get user interactions. Comments are wellcome. Can you explain in reasonable detail the extra properties needed for a device like this? You will need to document that anyway :-) Rather than implementing a private API it would be much more interesting to turn this into a public V4L2 API that everyone can use. Yes, here is a little description of them: Pilot is an audible tone sent by the device. pilot_frequency - Configures the frequency of the stereo pilot tone. pilot_deviation - Configures pilot tone frequency deviation level. pilot_enabled - Enables or disables the pilot tone feature. The si4713 device is capable of applying audio compression to the transmitted signal. acomp_enabled - Enables or disables the audio dynamic range control feature. acomp_gain - Sets the gain for audio dynamic range control. acomp_threshold - Sets the threshold level for audio dynamic range control. acomp_attack_time - Sets the attack time for audio dynamic range control. acomp_release_time - Sets the release time for audio dynamic range control. Limiter setups audio deviation limiter feature. Once a over deviation occurs, it is possible to adjust the front-end gain of the audio input and always prevent over deviation. limiter_enabled - Enables or disables the limiter feature. limiter_deviation - Configures audio frequency deviation level. limiter_release_time - Sets the limiter release time. power_level - Sets the output power level for signal transmission. Hmm, there are two ways to implement these: either make a bunch of VIDIOC's for each of these categories, or use extended controls to set all these values. I'm hardly an expert on FM transmitters, but it all seems reasonable to me (i.e., not too specific for this chip). I am leaning towards extended controls, since that's so easy to extend if needed in the future. And I still intend to add sysfs support to controls in the future. On the other hand, it's a bit harder to use compared to normal VIDIOCs. Could you please explain more about extended controls vs. VIDIOC's? Pointing drivers which uses one of those also would be worth. But yes, looks like moving this properties to some sort of v4l2 control looks better implementation. The spec explains it pretty well. The most up to date version of the spec is available here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html. Basically the extended controls API is more flexible than the older VIDIOC_S/G_CTRL ioctls, allowing to set controls atomically (either all are applied or none) and allowing for a wider range of types, although currently that feature isn't used. It's used by uvcvideo and by MPEG encoders (e.g. cx18, ivtv and others). Using VIDIOCs is easier, but much harder to make future-proof. One disadvantage of using extended controls is that it is harder to implement in drivers, although I plan on creating a much better solution for that in the coming months. With the new v4l framework it should be possible to move much of the control handling into the framework and so simplifying the drivers. RDS related rds_enabled - Enables or disables the RDS feature. rds_ps_name - Sets the RDS ps name field for transmission. rds_radio_text - Sets the RDS radio text for transmission. rds_pi - Sets the RDS PI field for
Re: USB DVB unplug: kernel BUG at kernel/module.c:912!
On Tue, 7 Apr 2009, Geert Uytterhoeven wrote:
On Mon, 6 Apr 2009, Andrew Morton wrote:
On Tue, 31 Mar 2009 14:28:45 +0200 (CEST) Geert Uytterhoeven
geert.uytterhoe...@sonycom.com wrote:
When unplugging a Sony PlayTV USB DVB adaptor from a PS3, I get
| kernel BUG at kernel/module.c:912!
on 2.6.29-06608-g15f7176.
Unplug Sony PlayTV USB:
Mar 31 14:01:28 ps3 kernel: [ 1437.101593] usb 1-2.1: USB disconnect,
address 6
Mar 31 14:01:28 ps3 kernel: [ 1437.133461] [ cut here
]
Mar 31 14:01:28 ps3 kernel: [ 1437.137955] kernel BUG at
kernel/module.c:912!
Mar 31 14:01:28 ps3 kernel: [ 1437.142408] Oops: Exception in kernel
mode, sig: 5 [#1]
Mar 31 14:01:28 ps3 kernel: [ 1437.146533] SMP NR_CPUS=2 PS3
Mar 31 14:01:28 ps3 kernel: [ 1437.150560] Modules linked in:
dvb_usb_dib0700 dib7000p dib3000mc dvb_usb dvb_core dib7000m
dibx000_common dib0070 i2c_core nfsd exportfs dm_crypt dm_mod sg ps3disk
ps3rom ps3flash ps3stor_lib ps3vram joydev evdev
Mar 31 14:01:28 ps3 kernel: [ 1437.155317] NIP: c008ae54 LR:
c008ae4c CTR: c008ae20
Mar 31 14:01:28 ps3 kernel: [ 1437.159706] REGS: c6987410 TRAP:
0700 Tainted: GW (2.6.29-06608-g15f7176)
Mar 31 14:01:28 ps3 kernel: [ 1437.164144] MSR: 80028032
EE,CE,IR,DR CR: 44004042 XER: 2000
Mar 31 14:01:28 ps3 kernel: [ 1437.168636] TASK = c69811c0[111]
'khubd' THREAD: c6984000 CPU: 0
Mar 31 14:01:28 ps3 kernel: [ 1437.168853] GPR00: c05777f8
c6987690 c0639b20
Mar 31 14:01:28 ps3 kernel: [ 1437.173362] GPR04: c00d1504
d29ced10 c065dc68
Mar 31 14:01:28 ps3 kernel: [ 1437.177894] GPR08:
c05777f8 d28092f8 c05777f8
Mar 31 14:01:28 ps3 kernel: [ 1437.182439] GPR12: d29d53f0
c0664200 00e9 c6d71830
Mar 31 14:01:28 ps3 kernel: [ 1437.186985] GPR16: 03e8
c6de9400 c6d71830
Mar 31 14:01:28 ps3 kernel: [ 1437.191559] GPR20:
c6cc6000 c6cc6000
Mar 31 14:01:28 ps3 kernel: [ 1437.196120] GPR24: 0001
c6cc63a0 c6bf90e8 c122c800
Mar 31 14:01:28 ps3 kernel: [ 1437.200676] GPR28: 0001
c312a000 d2b5c080 d28092f8
Mar 31 14:01:28 ps3 kernel: [ 1437.209542] NIP [c008ae54]
.symbol_put_addr+0x34/0x64
Mar 31 14:01:28 ps3 kernel: [ 1437.214040] LR [c008ae4c]
.symbol_put_addr+0x2c/0x64
Mar 31 14:01:28 ps3 kernel: [ 1437.218494] Call Trace:
Mar 31 14:01:28 ps3 kernel: [ 1437.222885] [c6987690]
[0001] 0x1 (unreliable)
Mar 31 14:01:28 ps3 kernel: [ 1437.227447] [c6987710]
[d29ce2e0] .dvb_frontend_detach+0x80/0x10c [dvb_core]
Mar 31 14:01:28 ps3 kernel: [ 1437.232018] [c69877a0]
[d2b4f088] .dvb_usb_adapter_frontend_exit+0x30/0x4c [dvb_usb]
Mar 31 14:01:28 ps3 kernel: [ 1437.236598] [c6987820]
[d2b4e4ec] .dvb_usb_exit+0x3c/0xf0 [dvb_usb]
Mar 31 14:01:28 ps3 kernel: [ 1437.241189] [c69878c0]
[d2b4e5ec] .dvb_usb_device_exit+0x4c/0x74 [dvb_usb]
Mar 31 14:01:28 ps3 kernel: [ 1437.245784] [c6987940]
[c0279ca0] .usb_unbind_interface+0x7c/0x138
Mar 31 14:01:28 ps3 kernel: [ 1437.250348] [c69879e0]
[c02430e8] .__device_release_driver+0xb8/0x100
Mar 31 14:01:28 ps3 kernel: [ 1437.254936] [c6987a70]
[c024325c] .device_release_driver+0x30/0x54
Mar 31 14:01:28 ps3 kernel: [ 1437.259518] [c6987b00]
[c02423a4] .bus_remove_device+0xe4/0x124
Mar 31 14:01:28 ps3 kernel: [ 1437.264104] [c6987b90]
[c023ff98] .device_del+0x178/0x1f8
Mar 31 14:01:28 ps3 kernel: [ 1437.268631] [c6987c20]
[c0276eb4] .usb_disable_device+0xb0/0x168
Mar 31 14:01:28 ps3 kernel: [ 1437.273175] [c6987cc0]
[c0271630] .usb_disconnect+0xc0/0x158
Mar 31 14:01:28 ps3 kernel: [ 1437.277606] [c6987d70]
[c027260c] .hub_thread+0x538/0xf14
Mar 31 14:01:28 ps3 kernel: [ 1437.281894] [c6987f00]
[c006c298] .kthread+0x78/0xc4
Mar 31 14:01:28 ps3 kernel: [ 1437.286192] [c6987f90]
[c00209e8] .kernel_thread+0x54/0x70
Mar 31 14:01:28 ps3 kernel: [ 1437.290510] Instruction dump:
Mar 31 14:01:28 ps3 kernel: [ 1437.294762] 7c0802a6 f8010010 7c7f1b78
f821ff81 4bfde4fd 6000 2fa3 409e0030
Mar 31 14:01:28 ps3 kernel: [ 1437.299233] 7fe3fb78 4bffc3b9 2fa3
409e000c 0fe0 4800 38210080 e8010010
Mar 31 14:01:28 ps3 kernel: [ 1437.304457] ---[ end trace
d1da44b3213415b8 ]---
Is it a
Re: [PATCH 1/6] cx18: Fix the handling of i2c bus registration error
On Tue, 2009-04-07 at 11:31 +0200, Jean Delvare wrote:
On Sat, 04 Apr 2009 08:46:00 -0400, Andy Walls wrote:
On Sat, 2009-04-04 at 14:26 +0200, Jean Delvare wrote:
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
---
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c
2009-03-01 16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
Reviewed-by: Andy Walls awa...@radix.net
If it matters:
Acked-by: Andy Walls awa...@radix.net
Regards,
Andy
[Context edited for clarity.]
Mauro, can you please apply this patch now? It is a bug fix not
directly related to my ir-kbd-i2c work, it would be nice to have it
applied quickly so that I don't have to carry the patch around.
Thanks,
--
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: [RFC] Anticipating lirc breakage
Hi Mike, Glad to see we all mostly agree on what to do now. I'll still answer some of your questions below, to clarify things even more. On Tue, 7 Apr 2009 01:19:02 -0500 (CDT), Mike Isely wrote: On Mon, 6 Apr 2009, Jean Delvare wrote: The bottom line is that we have to instantiate I2C devices for IR components regardless of the driver which will handle them (ir-kbd-i2c, lirc_i2c or another one). I can think of two different strategies here: 1* Instantiate driver-neutral I2C devices, named for example ir_video. Let both ir-kbd-i2c and lirc_i2c (and possibly others) bind to them. The first loaded driver gets to bind to the device. This isn't so different from the current situation, the only difference being that the choice of addresses to probe is moved to the bridge drivers. We can even go with separate names for some devices (for example ir_zilog), as each I2C driver can list which devices it supports. 2* Let the bridge drivers decide whether ir-kbd-i2c or lirc_i2c should drive any given device, by instantiating I2C devices with different names, for example ir_kbd for ir-kbd-i2c and lirc for lirc_i2c. This might give better out-of-the-box results for some devices and would make it possible to let the device drivers auto-load. There's a problem though for IR devices which are supported by both ir-kbd-i2c and lirc_i2c: not every user installs lirc, so it's not clear what devices should be created. We could default to ir_kbd and switch to lirc using a module parameter, as Mike Isely proposed for pvrusb2. I have a clear preference for the first strategy. I feel that creating devices for a specific driver is the wrong way to go, as we will certainly want to merge ir-kbd-i2c and lirc_i2c into a single driver in the future. However, I am not familiar enough with IR receivers to know for sure if the first strategy will work. I would welcome comments on this. Does anyone see a problem with strategy #1? Does anyone see notable advantages in strategy #2? I don't know if it will be possible or even make sense to merge ir-kbd-i2c and lirc_i2c. For example, if lirc_i2c is effectively a complete superset of ir-kbd-i2c, then what's there to merge? Seems to be in the end that ir-kbd-i2c will eventually go away, but certainly not until the question of merging lirc into the kernel is settled. I consider lirc_i2c replaces ir-kbd-i2c a valid implementation of merge ir-kbd-i2c and lirc_i2c into a single driver ;) I really don't care about the implementation details, as long as the outcome is that there is a single driver for every type of I2C-based IR receiver device, because then we can let udev load these drivers and the user experience will be much better. For now they must both continue to exist and so there must really be a way to ensure that the user can somehow control which is to be used - in cases where a legitimate choice exists. I agree. If we go with strategy #1 then my original patch set is probably very similar to the solution. The only differences would be the name of the I2C devices being created (ir_video instead of ir-kbd) and the list of addresses being probed (we'd need to add the addresses lirc_i2c supports but ir-kbd-i2c does not.) We would also need to ensure that ir-kbd-i2c doesn't crash when it sees a device at an address it doesn't support. I think #2 only makes sense if there is a clear defined convention for allowing the override of the desired name from userspace. For example, modprobe pvrusb2 ir_driver=lirc_i2c. I *definitely* would not want the bridge driver to force the user to one alternative in cases where two legitimate choices exist (which is what I first saw from your patch to the pvrusb2 driver and is partly why I nacked it so quickly). If #2 results in bridge drivers forcing the user to one IR driver, then I would not want to go that route. I agree as well... which means that #2 would require extra work on bridge drivers, which would all be reverted once lirc_i2c is merged. I think #1 is easier, but it does leave one with the situation again where loading ir_kbd_i2c again will cause it to bind to all bridge drivers looking for, say ir_video when perhaps that's not the right answer for a particular driver. (Right? I'm not sure if I totally understand that aspect yet.) Yes, you are right. I only point this out because it was considered to be one of the flaws of the previous scheme. However with that said, #1 is certainly no worse than before. #1 is indeed exactly the same functionally-wise as the current situation. It has the same limitations, but is also the easiest to implement. And the limitations will go away later when lirc_i2c is merged. Really in the end there must be a defined namespace for binding where someone looking for something I2C-ish (i.e. the bridge
Re: [RFC] Anticipating lirc breakage
Hi Mauro, On Tue, 7 Apr 2009 07:50:29 -0300, Mauro Carvalho Chehab wrote: On Tue, 7 Apr 2009 12:02:09 +0200 Jean Delvare kh...@linux-fr.org wrote: Hi Mike, Glad to see we all mostly agree on what to do now. I'll still answer some of your questions below, to clarify things even more. I don't understand why you are preferring to do some workaround, spending energy to add hooks at the kernel drivers to support out-of-tree drivers, instead of working to provide the proper solution. What I am proposing isn't a workaround, it is a fundamental part of the solution, and it is even the approach which requires the minimum amount of changes. This is as straightforward a solution as you can hope for. I'm against adding any hook on kernel to support an out-of-tree driver. I do not plan to add any hook. The plan is to instantiate all IR devices we know are present, and let ir-kbd-i2c bind to the ones it supports. The fact that another out-of-tree driver may optionally bind to these devices is a side effect. I would love to say let's just ignore lirc altogether, however 1* I don't think it makes any sense to break user systems when it is trivial for us to not break them and 2* I don't think it is smart to be rude with lirc developers are the exact moment they decide to attempt to merge their drivers in the kernel tree. From what I understood, lirc developers are interested on merging lirc drivers. We all agree that ir-kbd-i2c doesn't address all i2c IR's, and that lirc drivers provide support for the remaining ones. Yes, this is my understanding as well. So, let's just forget the workarounds and go straight to the point: focus on merging lirc-i2c drivers. Will this happen next week? I fear not. Which is why I can't wait for it. And anyway, in order to merge the lirc_i2c driver, it must be turned into a new-style I2C driver first, so bridge drivers must be prepared for this, which is _exactly_ what my patches are doing. -- 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 1/6] cx18: Fix the handling of i2c bus registration error
On Sat, 04 Apr 2009 08:46:00 -0400, Andy Walls wrote:
On Sat, 2009-04-04 at 14:26 +0200, Jean Delvare wrote:
* Return actual error values as returned by the i2c subsystem, rather
than 0 or 1.
* If the registration of the second bus fails, unregister the first one
before exiting, otherwise we are leaking resources.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
---
linux/drivers/media/video/cx18/cx18-i2c.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx18/cx18-i2c.c 2009-03-01
16:09:09.0 +0100
+++ v4l-dvb/linux/drivers/media/video/cx18/cx18-i2c.c 2009-04-03
18:45:18.0 +0200
@@ -214,7 +214,7 @@ static struct i2c_algo_bit_data cx18_i2c
/* init + register i2c algo-bit adapter */
int init_cx18_i2c(struct cx18 *cx)
{
- int i;
+ int i, err;
CX18_DEBUG_I2C(i2c init\n);
for (i = 0; i 2; i++) {
@@ -273,8 +273,18 @@ int init_cx18_i2c(struct cx18 *cx)
cx18_call_hw(cx, CX18_HW_GPIO_RESET_CTRL,
core, reset, (u32) CX18_GPIO_RESET_I2C);
- return i2c_bit_add_bus(cx-i2c_adap[0]) ||
- i2c_bit_add_bus(cx-i2c_adap[1]);
+ err = i2c_bit_add_bus(cx-i2c_adap[0]);
+ if (err)
+ goto err;
+ err = i2c_bit_add_bus(cx-i2c_adap[1]);
+ if (err)
+ goto err_del_bus_0;
+ return 0;
+
+ err_del_bus_0:
+ i2c_del_adapter(cx-i2c_adap[0]);
+ err:
+ return err;
}
void exit_cx18_i2c(struct cx18 *cx)
Reviewed-by: Andy Walls awa...@radix.net
[Context edited for clarity.]
Mauro, can you please apply this patch now? It is a bug fix not
directly related to my ir-kbd-i2c work, it would be nice to have it
applied quickly so that I don't have to carry the patch around.
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: Topro 6800 webcam driver
On Tue, 2009-04-07 at 15:13 +0400, Andrey Panin wrote:
On 097, 04 07, 2009 at 11:41:32AM +0200, Anders Blomdell wrote:
snip
+static const struct sd_desc sd_desc = {
+ .name = MODULE_NAME,
+ .ctrls = sd_ctrls,
+ .nctrls = ARRAY_SIZE(sd_ctrls),
+ .config = sd_config,
+ .init = sd_init,
+ .start = sd_start,
+ .stopN = sd_stopN,
+ .pkt_scan = sd_pkt_scan,
+ .querymenu = sd_querymenu,
+
+};
+
+static const __devinitdata struct usb_device_id device_table[] = {
+ {USB_DEVICE(0x06a2, 0x0003)},
+ {} /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, device_table);
+
+static int sd_probe(struct usb_interface *interface,
+ const struct usb_device_id *id)
+{
+ return gspca_dev_probe(interface, id, sd_desc, sizeof(struct sd),
+ THIS_MODULE);
+}
+
+static struct usb_driver tp6800_driver = {
+ .name = MODULE_NAME,
+ .id_table = device_table,
+ .probe = sd_probe,
+ .disconnect = gspca_disconnect,
+#ifdef CONFIG_PM
+ .suspend = gspca_suspend,
+ .resume = gspca_resume,
+#endif
+};
+
+/* Module loading and unloading */
+
+static int __init tp6800_init(void)
+{
+ int result;
+
+ result = usb_register(tp6800_driver);
+ if (result) {
+ printk(KERN_INFO %s usb_register_failed %d\n,
+ MODULE_NAME, result);
+ } else {
+ printk(KERN_INFO %s registered\n, MODULE_NAME);
+ }
+
+ return result;
+}
+
+static void __exit tp6800_exit(void)
+{
+ usb_deregister(tp6800_driver);
+ printk(KERN_INFO %s deregistered\n, MODULE_NAME);
+}
Are these registered/deregistered messages really useful ?
Looks like that gspca-framework use PDEBUG() messages for that.
For example, t613.c contains this:
static void __exit sd_mod_exit(void)
{
usb_deregister(sd_driver);
PDEBUG(D_PROBE, deregistered);
}
--
Best regards, Klimov Alexey
--
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: [RFC] Anticipating lirc breakage
On Tue, 7 Apr 2009 12:02:09 +0200 Jean Delvare kh...@linux-fr.org wrote: Hi Mike, Glad to see we all mostly agree on what to do now. I'll still answer some of your questions below, to clarify things even more. I don't understand why you are preferring to do some workaround, spending energy to add hooks at the kernel drivers to support out-of-tree drivers, instead of working to provide the proper solution. I'm against adding any hook on kernel to support an out-of-tree driver. From what I understood, lirc developers are interested on merging lirc drivers. We all agree that ir-kbd-i2c doesn't address all i2c IR's, and that lirc drivers provide support for the remaining ones. So, let's just forget the workarounds and go straight to the point: focus on merging lirc-i2c drivers. 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote: Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare: Anyone out there with a MSI t...@nywhere Plus that could help with testing? Here is a link to one of the initial reports by Henry, others are close to it. http://marc.info/?l=linux-videom=113324147429459w=2 There are two different variants of that MSI card, but that undocumented KS003 chip is the same on them. Great, thanks for the pointer. If I understand correctly, the KS003 has a state machine flow which causes the chip to stop answering when an invalid address is used on the bus and start answering again when a valid address other than his own is used. As the old i2c model relied a lot on probing, I am not surprised that this was a problem in the past. But with the new model, probes should become infrequent, so I suspect that the workaround may no longer be needed... except when i2c_scan=1 is used. I'd rather keep the workaround in place for the time being, and only once the ir-kbd-i2c changes have settled, try to remove it if someone really cares. -- 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/3] FM Transmitter driver
Hello again, On Fri, Apr 03, 2009 at 01:48:21PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: On Fri, Apr 03, 2009 at 01:29:27PM +0200, ext Hans Verkuil wrote: 2. Split driver into i2c driver (common/tunner?) and media/radio Not common/tuner, I think it can just go into media/radio. As long as it is a stand-alone i2c driver that can be reused. Ok. right. One question about this split. AFAIU, the split should go as: - one i2c driver under media/radio, which handles the i2c device itself and also registers itself as a v4l2_subdev_tuner of v4l2_subdevice api. - another driver under media/radio, which actually registers the v4l2_device as VFL_TYPE_RADIO and uses the i2c driver through the v4l2_subdev api (v4l2_subdev_call ??). In this case, I see this second driver as platform driver. Is that correct ? Yes, that's correct. Any good example of driver which does this? We do not currently have platform drivers that do that, but you can take a look at usbvision, which is probably the simplest of the lot when it comes to this. A more complicated example would be saa7134. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Embedded Linux Conference
* Tony Lindgren t...@atomide.com [090406 18:45]: On Mon, Apr 06, 2009 at 11:45:39PM +, Tony Lindgren wrote: On Tue, Apr 07, 2009 at 01:18:05AM +0200, Hans Verkuil wrote: * Dongsoo Kim dongsoo@gmail.com [090317 10:36]: snip snip How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ OK, let's meet at Harry's bar 7pm at 2020 Fillmore St between Pine and California St. They're closed until 4pm, so there's no reservation. But as it's Monday night, I'd assume there's plenty of space. In case of last minute changes, please check the page above. Not sure whether it will be as quiet as you hope: http://www.harrysbarsf.com/ There's apparently some championship game going on today. Just spoke withem on the phone, they'll just have some basketball on tv. So let's meet there and if it's too loud we can go somewhere else. Oops, Harry's bar is completely packed, let's meet at the bar next door to Haary's, it's called The Grove. So six people showed up last night for beers, we took few photos of this historic event :) http://www.muru.com/linux/omap/events/ Cheers, Tony -- 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] tda7432: Delete old driver history
The history of changes does belong to git. Signed-off-by: Jean Delvare kh...@linux-fr.org --- In general I wouldn't care too much but it happens that this specific comment triggers a false positive in one of my scripts, so I'd rather get rid of it. linux/drivers/media/video/tda7432.c | 14 -- 1 file changed, 14 deletions(-) --- v4l-dvb.orig/linux/drivers/media/video/tda7432.c2009-04-06 10:10:25.0 +0200 +++ v4l-dvb/linux/drivers/media/video/tda7432.c 2009-04-07 17:44:59.0 +0200 @@ -20,20 +20,6 @@ * loudness - set between 0 and 15 for varying degrees of loudness effect * * maxvol - set maximium volume to +20db (1), default is 0db(0) - * - * - * Revision: 0.7 - maxvol module parm to set maximium volume 0db or +20db - * store if muted so we can return it - * change balance only if flaged to - * Revision: 0.6 - added tone controls - * Revision: 0.5 - Fixed odd balance problem - * Revision: 0.4 - added muting - * Revision: 0.3 - Fixed silly reversed volume controls. :) - * Revision: 0.2 - Cleaned up #defines - * fixed volume control - * Added I2C_DRIVERID_TDA7432 - * added loudness insmod control - * Revision: 0.1 - initial version */ #include linux/module.h -- 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 -next] cx231xx: fix SND dependency build error
From: Randy Dunlap randy.dun...@oracle.com Don't select VIDEO_CX231XX_ALSA when SND is not enabled since selecting it won't cause SND to be enabled. ERROR: snd_pcm_period_elapsed [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_card_create [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_pcm_hw_constraint_integer [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_pcm_set_ops [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_pcm_lib_ioctl [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_card_free [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_card_register [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! ERROR: snd_pcm_new [drivers/media/video/cx231xx/cx231xx-alsa.ko] undefined! Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/video/cx231xx/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20090407.orig/drivers/media/video/cx231xx/Kconfig +++ linux-next-20090407/drivers/media/video/cx231xx/Kconfig @@ -6,7 +6,7 @@ config VIDEO_CX231XX select VIDEO_IR select VIDEOBUF_VMALLOC select VIDEO_CX25840 - select VIDEO_CX231XX_ALSA + select VIDEO_CX231XX_ALSA if SND ---help--- This is a video4linux driver for Conexant 231xx USB based TV cards. -- 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: Embedded Linux Conference
Oh! I can see my laptop! It was nice to meet you everyone. Sorry for not be talking with you much. I had to review my work with Hans before today's presentation. I appreciate for the beer. Cheers. Nate On Wed, Apr 8, 2009 at 12:53 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [090406 18:45]: On Mon, Apr 06, 2009 at 11:45:39PM +, Tony Lindgren wrote: On Tue, Apr 07, 2009 at 01:18:05AM +0200, Hans Verkuil wrote: * Dongsoo Kim dongsoo@gmail.com [090317 10:36]: snip snip How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ OK, let's meet at Harry's bar 7pm at 2020 Fillmore St between Pine and California St. They're closed until 4pm, so there's no reservation. But as it's Monday night, I'd assume there's plenty of space. In case of last minute changes, please check the page above. Not sure whether it will be as quiet as you hope: http://www.harrysbarsf.com/ There's apparently some championship game going on today. Just spoke withem on the phone, they'll just have some basketball on tv. So let's meet there and if it's too loud we can go somewhere else. Oops, Harry's bar is completely packed, let's meet at the bar next door to Haary's, it's called The Grove. So six people showed up last night for beers, we took few photos of this historic event :) http://www.muru.com/linux/omap/events/ Cheers, Tony -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- 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: s2255drv high quality mode and video status querying
On Tue, 7 Apr 2009, Dean A. wrote:
+static int vidioc_g_parm(struct file *file, void *priv,
+ struct v4l2_streamparm *sp)
+{
+ struct s2255_fh *fh = priv;
+ struct s2255_dev *dev = fh-dev;
+ if (sp-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
You do not need to check the buffer type, video_ioctl2 does it already.
--
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: s2255drv high quality mode and video status querying
From: Dean Anderson d...@sensoray.com
This patch adds V4L2 video status capability and V4L2_MODE_HIGHQUALITY
operation.
Signed-off-by: Dean Anderson d...@sensoray.com
--- v4l-dvb-1e670024659d/linux/drivers/media/video/s2255drv.c.orig
2009-04-07 10:38:42.0 -0700
+++ v4l-dvb-1e670024659d/linux/drivers/media/video/s2255drv.c 2009-04-07
10:42:51.0 -0700
@@ -57,7 +57,8 @@
#define FIRMWARE_FILE_NAME f2255usb.bin
-
+#define S2255_REV_MAJOR 1
+#define S2255_REV_MINOR 20
/* default JPEG quality */
#define S2255_DEF_JPEG_QUAL 50
@@ -75,9 +76,13 @@
#define S2255_LOAD_TIMEOUT (5000 + S2255_DSP_BOOTTIME)
#define S2255_DEF_BUFS 16
#define S2255_SETMODE_TIMEOUT 500
+#define S2255_VIDSTATUS_TIMEOUT 350
#define MAX_CHANNELS 4
-#define S2255_MARKER_FRAME 0x2255DA4AL
-#define S2255_MARKER_RESPONSE 0x2255ACACL
+#define S2255_MARKER_FRAME cpu_to_le32(0x2255DA4AL)
+#define S2255_MARKER_RESPONSE cpu_to_le32(0x2255ACACL)
+#define S2255_RESPONSE_SETMODE cpu_to_le32(0x01)
+#define S2255_RESPONSE_FW cpu_to_le32(0x10)
+#define S2255_RESPONSE_STATUS cpu_to_le32(0x20)
#define S2255_USB_XFER_SIZE(16 * 1024)
#define MAX_CHANNELS 4
#define MAX_PIPE_BUFFERS 1
@@ -100,14 +105,16 @@
#define LINE_SZ_DEF640
#define NUM_LINES_DEF 240
-
/* predefined settings */
#define FORMAT_NTSC1
#define FORMAT_PAL 2
+/* SCALE_4CIFS is the 2 fields merge into one */
#define SCALE_4CIFS1 /* 640x480(NTSC) or 704x576(PAL) */
#define SCALE_2CIFS2 /* 640x240(NTSC) or 704x288(PAL) */
#define SCALE_1CIFS3 /* 320x240(NTSC) or 352x288(PAL) */
+/* SCALE_4CIFSI is the 2 fields interpolated into one */
+#define SCALE_4CIFSI 4 /* 640x480(NTSC) or 704x576(PAL) high quality */
#define COLOR_YUVPL1 /* YUV planar */
#define COLOR_YUVPK2 /* YUV packed */
@@ -134,12 +141,12 @@
#define DEF_HUE0
/* usb config commands */
-#define IN_DATA_TOKEN 0x2255c0de
-#define CMD_2255 0xc2255000
-#define CMD_SET_MODE (CMD_2255 | 0x10)
-#define CMD_START (CMD_2255 | 0x20)
-#define CMD_STOP (CMD_2255 | 0x30)
-#define CMD_STATUS (CMD_2255 | 0x40)
+#define IN_DATA_TOKEN cpu_to_le32(0x2255c0de)
+#define CMD_2255 cpu_to_le32(0xc2255000)
+#define CMD_SET_MODE cpu_to_le32((CMD_2255 | 0x10))
+#define CMD_START cpu_to_le32((CMD_2255 | 0x20))
+#define CMD_STOP cpu_to_le32((CMD_2255 | 0x30))
+#define CMD_STATUS cpu_to_le32((CMD_2255 | 0x40))
struct s2255_mode {
u32 format; /* input video format (NTSC, PAL) */
@@ -181,7 +188,6 @@ struct s2255_dmaqueue {
struct list_headactive;
/* thread for acquisition */
struct task_struct *kthread;
- int frame;
struct s2255_dev*dev;
int channel;
};
@@ -211,16 +217,12 @@ struct s2255_pipeinfo {
u32 max_transfer_size;
u32 cur_transfer_size;
u8 *transfer_buffer;
- u32 transfer_flags;;
u32 state;
- u32 prev_state;
u32 urb_size;
void *stream_urb;
void *dev; /* back pointer to s2255_dev struct*/
u32 err_count;
- u32 buf_index;
u32 idx;
- u32 priority_set;
};
struct s2255_fmt; /*forward declaration */
@@ -239,14 +241,15 @@ struct s2255_dev {
struct video_device *vdev[MAX_CHANNELS];
struct list_heads2255_devlist;
struct timer_list timer;
- struct s2255_fw *fw_data;
- int board_num;
- int is_open;
+ struct s2255_fw *fw_data;
struct s2255_pipeinfo pipes[MAX_PIPE_BUFFERS];
struct s2255_bufferibuffer[MAX_CHANNELS];
struct s2255_mode mode[MAX_CHANNELS];
/* jpeg compression */
struct v4l2_jpegcompression jc[MAX_CHANNELS];
+ /* capture parameters (for high quality mode full size) */
+ struct v4l2_captureparm cap_parm[MAX_CHANNELS];
+
const struct s2255_fmt *cur_fmt[MAX_CHANNELS];
int cur_frame[MAX_CHANNELS];
int last_frame[MAX_CHANNELS];
@@ -265,9 +268,16 @@ struct s2255_dev {
int chn_configured[MAX_CHANNELS];
wait_queue_head_t wait_setmode[MAX_CHANNELS];
int setmode_ready[MAX_CHANNELS];
+ /* video status items */
+ int vidstatus[MAX_CHANNELS];
+ wait_queue_head_t wait_vidstatus[MAX_CHANNELS];
+ int vidstatus_ready[MAX_CHANNELS];
+
int chn_ready;
struct kref kref;
spinlock_t slock;
+ /* dsp firmware version (f2255usb.bin) */
+ int dsp_fw_ver;
};
#define to_s2255_dev(d) container_of(d, struct
Re: [PATCH/RFC] soc-camera: Convert to a platform driver
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
This is more or less the final version of the first step of the
v4l2-subdev conversion, hence, all affected driver authors / platform
maintainers are encouraged to review and test. I have eliminated
OK, here goes a preliminary review for the bits I maintain. I'll test fully this
weekend.
As a side note, I tried to apply your patch on top of linux-next-20090406. I was
a bit tedious. Would you tell me which tree you're based against, or even better
some git url ?
snip
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 97c93a7..5c8aabf 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -724,19 +724,19 @@ struct pxacamera_platform_data
mioa701_pxacamera_platform_data = {
.mclk_10khz = 5000,
};
-static struct soc_camera_link iclink = {
- .bus_id = 0, /* Must match id in pxa27x_device_camera in device.c */
-};
-
/* Board I2C devices. */
I would rather have :
/*
* Board I2C devices
*/
The remaining /* blurpblurg */ forms are a leftover in device comments.
snip
@@ -754,20 +754,21 @@ static struct platform_device var = {
\
.platform_data = pdata, \
.parent = tparent, \
}, \
-};
+}
No cookie for you for removing that semi-colon.
#define MIO_SIMPLE_DEV(var, strname, pdata) \
MIO_PARENT_DEV(var, strname, NULL, pdata)
-MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data)
+MIO_SIMPLE_DEV(mioa701_gpio_keys, gpio-keys,
mioa701_gpio_keys_data);
MIO_PARENT_DEV(mioa701_backlight, pwm-backlight, pxa27x_device_pwm0.dev,
mioa701_backlight_data);
-MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info)
-MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL)
-MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL)
-MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL)
-MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL)
-MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL)
+MIO_SIMPLE_DEV(mioa701_led,leds-gpio, gpio_led_info);
+MIO_SIMPLE_DEV(pxa2xx_pcm, pxa2xx-pcm, NULL);
+MIO_SIMPLE_DEV(pxa2xx_ac97,pxa2xx-ac97,NULL);
+MIO_PARENT_DEV(mio_wm9713_codec, wm9713-codec, pxa2xx_ac97.dev, NULL);
+MIO_SIMPLE_DEV(mioa701_sound, mioa701-wm9713, NULL);
+MIO_SIMPLE_DEV(mioa701_board, mioa701-board, NULL);
MIO_SIMPLE_DEV(gpio_vbus, gpio-vbus, gpio_vbus_data);
Please, don't change the indentation. You will face :
(a) conficts with patches in this merge window
(b) that's not the object of your patch anyway
(c) I like that indentation in that very specific case
+MIO_SIMPLE_DEV(mioa701_camera, soc-camera-pdrv,iclink[0]);
^
isn't iclink enough ?
static struct platform_device *devices[] __initdata = {
mioa701_gpio_keys,
@@ -781,6 +782,7 @@ static struct platform_device *devices[] __initdata = {
strataflash,
gpio_vbus,
mioa701_board,
+ mioa701_camera,
Please invert mioa701_board and mioa701_camera. The board should always be last
for suspend/resume purpose (yes, that would have deserved a comment, I hear you
:))
};
static void mioa701_machine_exit(void);
@@ -825,7 +827,6 @@ static void __init mioa701_machine_init(void)
pxa_set_i2c_info(i2c_pdata);
pxa_set_camera_info(mioa701_pxacamera_platform_data);
- i2c_register_board_info(0, ARRAY_AND_SIZE(mioa701_i2c_devices));
I'm wondering which version of mioa701.c had that line ... strange ...
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index cdd1ddb..425aec2 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
snip
@@ -938,40 +955,42 @@ static int mt9m111_video_probe(struct soc_camera_device
*icd)
dev_info(icd-dev, Detected a MT9M11x chip ID %x\n, data);
- ret = soc_camera_video_start(icd);
- if (ret)
- goto eisis;
-
mt9m111-autoexposure = 1;
mt9m111-autowhitebalance = 1;
mt9m111-swap_rgb_even_odd = 1;
mt9m111-swap_rgb_red_blue = 1;
- return 0;
-eisis:
ei2c:
+ soc_camera_video_stop(icd);
+
return ret;
}
static void mt9m111_video_remove(struct soc_camera_device *icd)
{
- struct mt9m111 *mt9m111 = container_of(icd, struct mt9m111, icd);
+ struct i2c_client *client = to_i2c_client(icd-control);
- dev_dbg(icd-dev, Video %x removed: %p, %p\n, mt9m111-client-addr,
- mt9m111-icd.dev.parent, mt9m111-icd.vdev);
- soc_camera_video_stop(mt9m111-icd);
+ dev_dbg(icd-dev, Video %x removed: %p, %p\n, client-addr,
+ icd-dev.parent, icd-vdev);
+
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Apr 7 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11440:1e670024659d gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-x86_64: WARNINGS fw/apps: WARNINGS sparse (linux-2.6.29): OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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/RFC] soc-camera: Convert to a platform driver
Robert Jarzmik robert.jarz...@free.fr writes: I'll test fully this weekend. I just made a first try, just to prepare my weekend. Even with Ming Lei patch reverted, and all statically built, I have no camera detected ... Is there something I need to know before attempting the brute force method (ie. DEBUG, printks etc ...) ? Cheers. -- Robert -- 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] V4L/DVB: cx231xx: remove unused #include linux/version.h's
Remove unused #include linux/version.h's in drivers/media/video/cx231xx/cx231xx-avcore.c drivers/media/video/cx231xx/cx231xx-vbi.c Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com --- drivers/media/video/cx231xx/cx231xx-avcore.c |1 - drivers/media/video/cx231xx/cx231xx-vbi.c|1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cx231xx/cx231xx-avcore.c b/drivers/media/video/cx231xx/cx231xx-avcore.c index 1be3881..6a94640 100644 --- a/drivers/media/video/cx231xx/cx231xx-avcore.c +++ b/drivers/media/video/cx231xx/cx231xx-avcore.c @@ -29,7 +29,6 @@ #include linux/bitmap.h #include linux/usb.h #include linux/i2c.h -#include linux/version.h #include linux/mm.h #include linux/mutex.h diff --git a/drivers/media/video/cx231xx/cx231xx-vbi.c b/drivers/media/video/cx231xx/cx231xx-vbi.c index 9418052..e97b802 100644 --- a/drivers/media/video/cx231xx/cx231xx-vbi.c +++ b/drivers/media/video/cx231xx/cx231xx-vbi.c @@ -26,7 +26,6 @@ #include linux/bitmap.h #include linux/usb.h #include linux/i2c.h -#include linux/version.h #include linux/mm.h #include linux/mutex.h -- 1.6.0.4 -- 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 3/6] ir-kbd-i2c: Switch to the new-style device binding model
Jean Delvare wrote: On Mon, 06 Apr 2009 23:10:36 +0200, hermann pitton wrote: Am Montag, den 06.04.2009, 10:40 +0200 schrieb Jean Delvare: Anyone out there with a MSI t...@nywhere Plus that could help with testing? Here is a link to one of the initial reports by Henry, others are close to it. http://marc.info/?l=linux-videom=113324147429459w=2 There are two different variants of that MSI card, but that undocumented KS003 chip is the same on them. Great, thanks for the pointer. If I understand correctly, the KS003 has a state machine flow which causes the chip to stop answering when an invalid address is used on the bus and start answering again when a valid address other than his own is used. As the old i2c model relied a lot on probing, I am not surprised that this was a problem in the past. But with the new model, probes should become infrequent, so I suspect that the workaround may no longer be needed... except when i2c_scan=1 is used. I'd rather keep the workaround in place for the time being, and only once the ir-kbd-i2c changes have settled, try to remove it if someone really cares. Regarding the KS003 ( KS007; the other mystery chip): Upon further investigation of some info from a post from last year (http://www.linuxtv.org/pipermail/linux-dvb/2008-January/022634.html), it appears that these (assuming that they are the same IC across the various MSI, Leadtek KWorld cards; and I believe that to be true) are the AT8PS54/S56 chip from Feeling Technology ... the datasheet for that part is available through a google search probing further (as I had never heard of FT before and so I looked them up), it looks like FT renamed and/or upgraded the chip to the FM8PS54/S56 ... the near identical datasheet for that second version is also available: http://www.feeling-tech.com.tw/km-master/front/bin/ptdetail.phtml?Part=M1-05Category=100018 -- 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
