Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Sun, 13 Dec 2009 21:46:28 +0100 Németh Márton nm...@freemail.hu wrote: It seems that kernels before 2.6.24 (inclusively) do not have __devinitconst, so conex.c and etoms.c can only build with 2.6.25 and later. Should USB_GSPCA_CONEX and USB_GSPCA_ETOMS be added to v4l/versions.txt? The fix is not the right one. Some other gspca subdrivers use __devinitconst (pac7302, pac7311, sonixb and spca506). The fix is to define the macro for kernels 2.6.25: diff -r 174ad3097f17 linux/drivers/media/video/gspca/gspca.h --- a/linux/drivers/media/video/gspca/gspca.h Sun Dec 13 18:11:07 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.h Mon Dec 14 09:28:51 2009 +0100 @@ -11,6 +11,10 @@ /* compilation option */ #define GSPCA_DEBUG 1 +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25) +#define __devinitconst __section(.devinit.rodata) +#endif + #ifdef GSPCA_DEBUG /* GSPCA our debug messages */ extern int gspca_debug; I will ask to upload the changeset (actually in my test repository) as soon as it is validated (i.e. if it works with hal). -- 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
Dvico FusionHDTV Dual Express PCIe tuner issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I've got a Dvico FusionHDTV Dual Express PCIe tuner, which returns the following lspci output: lspci output: 03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: DViCO Corporation Device db78 Flags: fast devsel, IRQ 16 Memory at fb80 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [80] Power Management version 2 Capabilities: [90] Vital Product Data ? Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [200] Virtual Channel ? Kernel modules: cx23885 I understood the digital side of the card was supported but I can't get it to work. I've tried the cx23885 module in v4l-dvb HEAD but get the following error ( on kernel 2.6.27.41-170.2.117.fc10.i686): # modprobe cx23885 FATAL: Error inserting cx23885 (/lib/modules/2.6.27.41-170.2.117.fc10.i686/kernel/drivers/media/video/cx23885/cx23885.ko): Unknown symbol in module, or unknown parameter (see dmesg) dmesg output: cx23885: Unknown symbol v4l2_i2c_new_probed_subdev cx23885: Unknown symbol videobuf_dvb_alloc_frontend cx23885: Unknown symbol v4l2_i2c_subdev_addr cx23885: Unknown symbol videobuf_dvb_get_frontend cx23885: Unknown symbol v4l2_device_register cx23885: Unknown symbol videobuf_dvb_unregister_bus cx23885: Unknown symbol videobuf_dvb_register_bus cx23885: Unknown symbol v4l2_i2c_tuner_addrs cx23885: Unknown symbol v4l2_device_unregister cx23885: Unknown symbol v4l2_i2c_new_subdev cx23885: Unknown symbol v4l2_i2c_new_probed_subdev cx23885: Unknown symbol videobuf_dvb_alloc_frontend cx23885: Unknown symbol v4l2_i2c_subdev_addr cx23885: Unknown symbol videobuf_dvb_get_frontend cx23885: Unknown symbol v4l2_device_register cx23885: Unknown symbol videobuf_dvb_unregister_bus cx23885: Unknown symbol videobuf_dvb_register_bus cx23885: Unknown symbol v4l2_i2c_tuner_addrs cx23885: Unknown symbol v4l2_device_unregister cx23885: Unknown symbol v4l2_i2c_new_subdev cx23885: Unknown symbol v4l2_i2c_new_subdev_cfg cx23885: Unknown symbol videobuf_dvb_alloc_frontend cx23885: Unknown symbol v4l2_i2c_subdev_addr cx23885: Unknown symbol ir_codes_hauppauge_new_table cx23885: Unknown symbol v4l2_device_register_subdev cx23885: Unknown symbol v4l_bound_align_image cx23885: Unknown symbol ir_rc5_timer_keyup cx23885: Unknown symbol v4l2_device_unregister_subdev cx23885: Unknown symbol videobuf_dvb_get_frontend cx23885: Unknown symbol ir_input_init cx23885: Unknown symbol v4l2_device_register cx23885: Unknown symbol videobuf_dvb_unregister_bus cx23885: Unknown symbol ir_input_nokey cx23885: Unknown symbol ir_rc5_decode cx23885: Unknown symbol ir_input_unregister cx23885: Unknown symbol videobuf_dvb_register_bus cx23885: Unknown symbol v4l2_i2c_tuner_addrs cx23885: Unknown symbol v4l2_device_unregister cx23885: Unknown symbol ir_input_keydown cx23885: Unknown symbol ir_input_register cx23885: Unknown symbol v4l2_i2c_new_subdev_cfg cx23885: Unknown symbol videobuf_dvb_alloc_frontend cx23885: Unknown symbol v4l2_i2c_subdev_addr cx23885: Unknown symbol ir_codes_hauppauge_new_table cx23885: Unknown symbol v4l2_device_register_subdev cx23885: Unknown symbol v4l_bound_align_image cx23885: Unknown symbol ir_rc5_timer_keyup cx23885: Unknown symbol v4l2_device_unregister_subdev cx23885: Unknown symbol videobuf_dvb_get_frontend cx23885: Unknown symbol ir_input_init cx23885: Unknown symbol v4l2_device_register cx23885: Unknown symbol videobuf_dvb_unregister_bus cx23885: Unknown symbol ir_input_nokey cx23885: Unknown symbol ir_rc5_decode cx23885: Unknown symbol ir_input_unregister cx23885: Unknown symbol videobuf_dvb_register_bus cx23885: Unknown symbol v4l2_i2c_tuner_addrs cx23885: Unknown symbol v4l2_device_unregister cx23885: Unknown symbol ir_input_keydown cx23885: Unknown symbol ir_input_register Anyone have any ideas/a fix for this? Regards James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG
Re: Compile Error - ir-keytable
Jeremy Simmons wrote: I'm having the same problem. Any solution? The new IR keycode is not compatible with any kernel older than 2.6.22. Also, newer versions may even require latter codes, due to the sysfs code. The fix is simple: - Don't compile any code from ir-sysfs.c with older kernels; - Don't implement EVIO[G|S]KEYCODE ioctls; - Replace the new code to get a key by an old code at ir-keytable.c, if kernels = 2.6.22. There's nothing reasonable that we can do to support keycode replacements with older kernels, as the scancode tables were expanded to 16 bits (and will probably be expanded to 32 or 64 bits), and, with the legacy kernels, the scancode/keycode table needs to be an array of the size of the scancode space. So, a keycode table for 32 bits would waste 4Gb of ram (while we're still using 16 bits, the table won't be that big, but as we expect to soon support RC6 protocols, it is not worth to port a code for 16 bits that will just be dropped in a month or two). Due to that, the support for 2.6.22 kernels will provide a limited IR code, after the backport: just the bundled IR will work. I asked Douglas to do this backport after I finish the main changes at the module. He'll likely start looking on it soon, as I've merged late yesterday the changes. -Jeremy * Subject: Compile Error - ir-keytable * From: David Carlo dca...@ * Date: Wed, 2 Dec 2009 11:56:22 -0500 Hello. I'm compiling the v4l kernel drivers in an attempt to use my hdpvr with CentOS 5.4. When I compile v4l, I'm getting this error: = snip CC [M] /usr/local/src/v4l-dvb/v4l/ir-functions.o CC [M] /usr/local/src/v4l-dvb/v4l/ir-keymaps.o CC [M] /usr/local/src/v4l-dvb/v4l/ir-keytable.o /usr/local/src/v4l-dvb/v4l/ir-keytable.c: In function 'ir_g_keycode_from_table': /usr/local/src/v4l-dvb/v4l/ir-keytable.c:181: error: implicit declaration of function 'input_get_drvdata' /usr/local/src/v4l-dvb/v4l/ir-keytable.c:181: warning: initialization makes pointer from integer without a cast /usr/local/src/v4l-dvb/v4l/ir-keytable.c: In function 'ir_input_free': /usr/local/src/v4l-dvb/v4l/ir-keytable.c:236: warning: initialization makes pointer from integer without a cast make[3]: *** [/usr/local/src/v4l-dvb/v4l/ir-keytable.o] Error 1 make[2]: *** [_module_/usr/local/src/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.18-164.6.1.el5-x86_64' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/src/v4l-dvb/v4l' make: *** [all] Error 2 = Here are the stats on my box: CentOS 5.4 x86_64 kernel 2.6.18-164.6.1.el5-x86_64 gcc 4.1.2 Has anyone else seen this? --Dave -- 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 -- 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: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200
2009/12/9 Newsy Paper newspaperman_germ...@yahoo.com: Hi, no matter if I use Igors or Manus driver, there's no lock on 11303 h 22000 2/3 8psk. Other users at vdr-portal report same problem. The strange thing is that all other transponders that use 22000 2/3 8psk do work but this transponder doesn't. It worked fine until december 3rd when uplink moved to Vienna. I think they changed a parameter like rolloff or inversion and the dvb-s2 part of stb6100 is buggy. It works again. Very strange. $ sudo ./scan-s2 -x -2 -O S19.2E ORF.ini API major 5, minor 0 scanning ORF.ini using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S2 11303000 H 2200 2/3 35 8PSK -- Using DVB-S2 tune to: 11303:hC23M5O35S1:S19.2E:22000: DVB-S IF freq is 1553000 parse_section, section number 0 out of 0...! service_id = 0x0 service_id = 0x132F pmt_pid = 0x6B service_id = 0x1330 pmt_pid = 0x6C service_id = 0x1331 pmt_pid = 0x6D parse_section, section number 0 out of 0...! VIDEO : PID 0x0DFF AUDIO : PID 0x0E00 AUDIO : PID 0x0E01 AC3 : PID 0x0E03 TELETEXT : PID 0x0E04 parse_section, section number 0 out of 0...! CA ID : PID 0x0D05 CA ID : PID 0x1702 CA ID : PID 0x1833 CA ID : PID 0x0648 CA ID : PID 0x0D95 CA ID : PID 0x09C4 VIDEO : PID 0x0B68 AUDIO : PID 0x0B69 AC3 : PID 0x0B6B AUDIO : PID 0x0B6A TELETEXT : PID 0x0B6D parse_section, section number 0 out of 0...! CA ID : PID 0x0D05 CA ID : PID 0x1702 CA ID : PID 0x1833 CA ID : PID 0x0648 CA ID : PID 0x0D95 CA ID : PID 0x09C4 VIDEO : PID 0x0780 AUDIO : PID 0x0781 AC3 : PID 0x0783 AUDIO : PID 0x0782 TELETEXT : PID 0x0785 parse_section, section number 0 out of 0...! 0x03EF 0x132F: pmt_pid 0x006B ORF -- ORF1 HD (running, scrambled) 0x03EF 0x1330: pmt_pid 0x006C ORF -- ORF2 HD (running, scrambled) 0x03EF 0x1331: pmt_pid 0x006D ServusTV -- Servus TV HD (running) parse_section, section number 0 out of 0...! dumping lists (3 services) ORF1 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:1920:1921=ger,1922=ENG;1923=ger:1925:D05,1702,1833,648,D95,9C4:4911:1:1007:0 ORF2 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:2920:2921=ger,2922=ENG;2923=ger:2925:D05,1702,1833,648,D95,9C4:4912:1:1007:0 Servus TV HD;ServusTV:11303:hC23M5O35S1:S19.2E:22000:3583:3584=ger,3585=eng;3587=ger:3588:0:4913:1:1007:0 Regards Oleg Roitburd -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Jean-Francois Moine wrote: On Sun, 13 Dec 2009 21:46:28 +0100 Németh Márton nm...@freemail.hu wrote: It seems that kernels before 2.6.24 (inclusively) do not have __devinitconst, so conex.c and etoms.c can only build with 2.6.25 and later. Should USB_GSPCA_CONEX and USB_GSPCA_ETOMS be added to v4l/versions.txt? The fix is not the right one. Some other gspca subdrivers use __devinitconst (pac7302, pac7311, sonixb and spca506). The fix is to define the macro for kernels 2.6.25: diff -r 174ad3097f17 linux/drivers/media/video/gspca/gspca.h --- a/linux/drivers/media/video/gspca/gspca.h Sun Dec 13 18:11:07 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.h Mon Dec 14 09:28:51 2009 +0100 @@ -11,6 +11,10 @@ /* compilation option */ #define GSPCA_DEBUG 1 +#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 25) +#define __devinitconst __section(.devinit.rodata) +#endif + Better to add it at v4l/compat.h, to avoid polluting the drivers with compat code. 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: New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)
Hi, Am Montag, den 14.12.2009, 08:26 +0100 schrieb dvblinux: The complete name of the board is: ASUS My Cinema PS3-100/PTS/FM/AV/RC ouch :-) You're right: It features the same features than the ASUS My Cinema P7131 Hybrid that is: S-Video in, Composite and audio in with a special splitter cord, an FM tuner and IR remote control. All connectors are the same for both cards, but the additionnal DVB-S. The remote control seems to behave exactely the same as P7131, i.e new entries in /dev/input/ as a regular keyboard. I'll post additionnal stuff later, thanks for your answer. Regards. the card is a little different than the OEM 3in1 it seems. Just some hints for your further testing. On card=147 the DVB-T demod is at 0x0b, but on P7131 Hybrid LNA on 0x08. You might want to change it in saa7134-dvb.c in the 3in1_config and in saa7134-cards.c for analog initialization. To test on DVB-S you need to pass use_frontend=1 to the saa7134-dvb module. That tuner is at 0x60, might be different for you. On later P7131 type of cards, like Dual and Hybrid LNA, there is a female antenna input connector _also_ for radio on the board. The DVB-T RF input is switched to that shared radio/DVB-T input with antenna_switch = 2 and gpio 0x020 for analog radio. Analog TV remains on the other RF input. The 3in1 OEM version has a male radio antenna input on the card, so with antenna_switch = 1 analog TV and DVB-T are on the same single female connector on that one, only for radio we switch to the other. Good luck, Hermann Le lundi 14 décembre 2009 à 02:36 +0100, hermann pitton a écrit : Hi, sorry for delay, no time for the list during the last days. Am Freitag, den 11.12.2009, 16:02 +0100 schrieb dvbli...@free.fr: Hi all, I'm new on this list. I modified on my own the SAA driver to manage an ASUS PS3-100 combo card not supported yet in current version. It features two DVB-S and DVB-T receivers packed on the same PCI card. I'm not aware of such an Asus PCI card with two DVB-S and DVB-T receivers. We might hang in wording ... Maybe one DVB-S, one DVB-T/analog hybrid tuner/demod and also support for analog radio and external S-Video/Composite and analog audio in? The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed thru the existing driver after a light patch in the driver source (and card.c): copying relevant stuff from (1043:4876) to (1043:48cd). I'm not a developper, how to share my successfull experiments ? We have support for the Asus Tiger 3in1 since last summer. This board was OEM only and also does not come with a remote, but your stuff is very likely based on that one. Please try all functions and inputs and post related dmesg output loading the saa7134 driver with card=147 i2c_scan=1. It has the same LNA config like the ASUS P7131 Hybrid LNA too. I can't tell anything about a possible remote, but last on Asus was a transmitter labeled PC-39 that far and that one we do support. 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: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote: Hi Mauro, At last soc-camera and mediabus lot for 2.6.33. Note, that one of this patches adds new fourcc codes. A patch for their documentation will be submitted immediately. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 30 changesets: 01/30: tw9910: The driver can also handle revision 1 of the chip http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 02/30: soc-camera: remove no longer needed struct members http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 04/30: soc-camera: fix multi-line comment coding style http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client fails http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 07/30: soc-camera: add a private field to struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c 09/30: soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 11/30: tw9910: Add revision control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 12/30: tw9910: simplify chip ID calculation http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 13/30: tw9910: Tri-state pins when idle http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 14/30: tw9910: Add power control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f 15/30: tw9910: tw9910_set_hsync clean up http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 16/30: tw9910: Add revision control to tw9910_set_hsync http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a 18/30: soc-camera: convert to the new mediabus API http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c 21/30: mt9t031: make the use of the soc-camera client API optional http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b 25/30: tw9910: modify V/H outpit pin setting to use VALID http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 26/30: tw9910: modify output format http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 27/30: tw9910: remove cropping http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a 28/30: tw9910: Add sync polarity support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 29/30: soc-camera: Add mt9t112 camera driver http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 30/30: sh_mobile_ceu_camera: Remove frame size page alignment http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt | 157 + b/linux/arch/sh/boards/mach-ap325rxa/setup.c | 657 +++ b/linux/arch/sh/boards/mach-kfr2r09/setup.c| 622 ++ b/linux/drivers/media/video/mt9t112.c | 1177 + b/linux/drivers/media/video/soc_mediabus.c | 157 +
Re: [PULL] soc-camera and mediabus
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote: Guennadi Liakhovetski wrote: Hi Mauro, At last soc-camera and mediabus lot for 2.6.33. Note, that one of this patches adds new fourcc codes. A patch for their documentation will be submitted immediately. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 30 changesets: 01/30: tw9910: The driver can also handle revision 1 of the chip http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 02/30: soc-camera: remove no longer needed struct members http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 04/30: soc-camera: fix multi-line comment coding style http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client fails http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 07/30: soc-camera: add a private field to struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c 09/30: soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 11/30: tw9910: Add revision control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 12/30: tw9910: simplify chip ID calculation http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 13/30: tw9910: Tri-state pins when idle http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 14/30: tw9910: Add power control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f 15/30: tw9910: tw9910_set_hsync clean up http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 16/30: tw9910: Add revision control to tw9910_set_hsync http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a 18/30: soc-camera: convert to the new mediabus API http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c 21/30: mt9t031: make the use of the soc-camera client API optional http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b 25/30: tw9910: modify V/H outpit pin setting to use VALID http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 26/30: tw9910: modify output format http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 27/30: tw9910: remove cropping http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a 28/30: tw9910: Add sync polarity support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 29/30: soc-camera: Add mt9t112 camera driver http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 30/30: sh_mobile_ceu_camera: Remove frame size page alignment http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt | 157 + b/linux/arch/sh/boards/mach-ap325rxa/setup.c | 657 +++ b/linux/arch/sh/boards/mach-kfr2r09/setup.c| 622 ++
RE: Latest stack that can be merged on top of linux-next tree
Guennadi, I marged relevant files from the latest of your v4l tree after seeing your pull request. I worked fine for VGA capture. But I need to enable SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we remove this restriction from KConfig? I plan to send a vpfe capture patch to support capture using this driver this week. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Friday, December 11, 2009 7:47 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: Latest stack that can be merged on top of linux-next tree Hi Muralidharan On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote: Guennadi, I am not sure if your MT9T031 changes are part of linux-next tree at v4l-dvb. If not, can you point me to the latest stack that I can apply on top of linux-next tree to get your latest changes for MT9T031 sensor driver? As you probably have seen, I posted a pull request a couple of hours ago, which also contains the change to mt9t031, that you're asking about. I plan to do integrate sensor driver with vpfe capture driver this week. BTW, Is there a driver for the PCA9543 i2c switch that is part of MT9T031 headboard? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Latest stack that can be merged on top of linux-next tree
On Mon, 14 Dec 2009, Karicheri, Muralidharan wrote: Guennadi, I marged relevant files from the latest of your v4l tree after seeing your pull request. I worked fine for VGA capture. Good. But I need to enable SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we remove this restriction from KConfig? Sure, as long as we have a valid case where the driver can and does work without soc-camera, which we now do, we shall remove this dependency. I plan to send a vpfe capture patch to support capture using this driver this week. Good, looking forward to it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: Latest stack that can be merged on top of linux-next tree
Guennadi, I plan to send a vpfe capture patch to support capture using this driver this week. Good, looking forward to it. I will copy you on the request for reviewing the patch. It will be great if you can review the same. -Murali Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PULL] soc-camera and mediabus
Hi All,
3) it would be interesting to patch the other sensor drivers to be compatible
with soc_camera (mt9v011/ov7670);
Well, this could be done, yes, but does it make sense to do this blindly
without any hardware to test? I would rather add such conversions on a
one-by-one basis as need arises.
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet. For reference, a quick and dirty
cut of the patch is below. Some thought is needed on how to deal with the
sections
that currently need to be different for the soc-camera and non soc camera uses.
(mainly the registration code in probe).
On another note, does anyone have an objection to making the set_bus_param
function optional? At the moment we are adding null functions for those
devices that can't actually change anything which seems a little pointless.
Jonathan
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..e57c3b5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#include media/soc_camera.h
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
@@ -545,7 +546,7 @@ static struct ov7670_format_struct {
.bpp= 1
},
};
-#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
+
/*
@@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int
hstart, int hstop,
return ret;
}
+static enum v4l2_mbus_pixelcode ov7670_codes[] = {
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_RGB565_2X8_LE,
+};
-static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
+static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum
v4l2_mbus_pixelcode *code)
{
- struct ov7670_format_struct *ofmt;
-
- if (fmt-index = N_OV7670_FMTS)
+ if (index = ARRAY_SIZE(ov7670_codes))
return -EINVAL;
- ofmt = ov7670_formats + fmt-index;
- fmt-flags = 0;
- strcpy(fmt-description, ofmt-desc);
- fmt-pixelformat = ofmt-pixelformat;
+ *code = ov7670_codes[index];
return 0;
}
static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
- struct v4l2_format *fmt,
- struct ov7670_format_struct **ret_fmt,
- struct ov7670_win_size **ret_wsize)
+ struct v4l2_mbus_framefmt *mf,
+ struct ov7670_format_struct **ret_fmt,
+ struct ov7670_win_size **ret_wsize)
{
int index;
struct ov7670_win_size *wsize;
- struct v4l2_pix_format *pix = fmt-fmt.pix;
- for (index = 0; index N_OV7670_FMTS; index++)
- if (ov7670_formats[index].pixelformat == pix-pixelformat)
- break;
- if (index = N_OV7670_FMTS) {
- /* default to first format */
- index = 0;
- pix-pixelformat = ov7670_formats[0].pixelformat;
- }
- if (ret_fmt != NULL)
- *ret_fmt = ov7670_formats + index;
- /*
-* Fields: the OV devices claim to be progressive.
-*/
- pix-field = V4L2_FIELD_NONE;
+ mf-field = V4L2_FIELD_NONE;
/*
* Round requested image size down to the nearest
* we support, but not below the smallest.
*/
for (wsize = ov7670_win_sizes; wsize ov7670_win_sizes + N_WIN_SIZES;
wsize++)
- if (pix-width = wsize-width pix-height = wsize-height)
+ if ( mf-width = wsize-width mf-height = wsize-height)
break;
if (wsize = ov7670_win_sizes + N_WIN_SIZES)
wsize--; /* Take the smallest one */
@@ -722,22 +708,34 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
/*
* Note the size we'll actually handle.
*/
- pix-width = wsize-width;
- pix-height = wsize-height;
- pix-bytesperline = pix-width*ov7670_formats[index].bpp;
- pix-sizeimage = pix-height*pix-bytesperline;
+ mf-width = wsize-width;
+ mf-height = wsize-height;
+ switch (mf-code) {
+ case V4L2_MBUS_FMT_RGB565_2X8_LE:
+ mf-colorspace = V4L2_COLORSPACE_SRGB;
+ if (ret_fmt != NULL)
+ *ret_fmt = ov7670_formats + 2;
+ break;
+ default:
+ mf-code = V4L2_MBUS_FMT_YUYV8_2X8;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ mf-colorspace = V4L2_COLORSPACE_JPEG;
+ if (ret_fmt != NULL)
+ *ret_fmt = ov7670_formats;
+ break;
+ }
return 0;
}
-static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *fmt)
+static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt
*mf)
{
- return
Re: [PULL] soc-camera and mediabus
Guennadi Liakhovetski wrote: On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote: Guennadi Liakhovetski wrote: Hi Mauro, At last soc-camera and mediabus lot for 2.6.33. Note, that one of this patches adds new fourcc codes. A patch for their documentation will be submitted immediately. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 30 changesets: 01/30: tw9910: The driver can also handle revision 1 of the chip http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 02/30: soc-camera: remove no longer needed struct members http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 04/30: soc-camera: fix multi-line comment coding style http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client fails http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 07/30: soc-camera: add a private field to struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c 09/30: soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 11/30: tw9910: Add revision control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 12/30: tw9910: simplify chip ID calculation http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 13/30: tw9910: Tri-state pins when idle http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 14/30: tw9910: Add power control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f 15/30: tw9910: tw9910_set_hsync clean up http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 16/30: tw9910: Add revision control to tw9910_set_hsync http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a 18/30: soc-camera: convert to the new mediabus API http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c 21/30: mt9t031: make the use of the soc-camera client API optional http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b 25/30: tw9910: modify V/H outpit pin setting to use VALID http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 26/30: tw9910: modify output format http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 27/30: tw9910: remove cropping http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a 28/30: tw9910: Add sync polarity support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 29/30: soc-camera: Add mt9t112 camera driver http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 30/30: sh_mobile_ceu_camera: Remove frame size page alignment http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt | 157 + b/linux/arch/sh/boards/mach-ap325rxa/setup.c | 657 +++ b/linux/arch/sh/boards/mach-kfr2r09/setup.c| 622 ++ b/linux/drivers/media/video/mt9t112.c | 1177 +
Re: [PULL] soc-camera and mediabus
Jonathan Cameron wrote: Hi All, 3) it would be interesting to patch the other sensor drivers to be compatible with soc_camera (mt9v011/ov7670); Well, this could be done, yes, but does it make sense to do this blindly without any hardware to test? I would rather add such conversions on a one-by-one basis as need arises. I'm working on the ov7670. I've added the media bus stuff to what I've previously posted but I haven't tested as yet. For reference, a quick and dirty cut of the patch is below. Some thought is needed on how to deal with the sections that currently need to be different for the soc-camera and non soc camera uses. (mainly the registration code in probe). True. Couldn't this be a library that handles the code difference between soc-camera platform-data bits and normal subdev? Even better: couldn't this code be handled by soc_camera core and just use subdev interface for both cases? After finishing the patch, please ping me. I have here an OLPC with ov7670 where I can test if the new code doesn't break the cafe_ccic driver. You'll probably need to touch on it, as it will need to use the new mediabus API to talk with ov7670. On another note, does anyone have an objection to making the set_bus_param function optional? At the moment we are adding null functions for those devices that can't actually change anything which seems a little pointless. Agreed. 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
[PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following changeset: 01/01: Add support for yet another DvbWorld, TeVii and Prof USB devices http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=ab7f084779b0 Kconfig |8 - dw2102.c | 456 ++- 2 files changed, 315 insertions(+), 149 deletions(-) Thanks, Igor -- 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: [linux-dvb] siano firmware and behaviour after resuming power
Em Thu, 03 Dec 2009 09:53:21 +0100 Luca Olivetti l...@ventoso.org escreveu: Ah, ok, I got my sources from linuxtv and there's no firmware there. In fact, one of the search results for siano firmware was a message from Mauro asking Uri (who doesn't work for siano any more) for permission to distribute the firmware, with no follow-ups. Yes. I also tried with Udi, without success so far. It would be really wonderful if Siano could get binary distribution rights for the firmware. Cheers, Mauro. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Sat, 12 Dec 2009 16:00:27 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. $ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado abort: error: Temporary failure in name resolution I can't pull. Your site is not responding. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Mon, 14 Dec 2009 14:07:42 -0200 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 12 Dec 2009 16:00:27 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. $ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado abort: error: Temporary failure in name resolution I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. Cheers, Mauro 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. I'll be reviewing the patch series. Cheers, Mauro Pushing from remote site http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: hvr-1600-alsa-2 Number of patches: 14 /tmp/newpatches/hg_hvr-1600-alsa-2_01.patch with cs=878a34e7beac First patch. Patch against an older patch: changeset: 13370:7477df192a59 user:Mauro Carvalho Chehab mche...@redhat.com date:Wed Nov 18 05:12:04 2009 -0200 summary: Add a list of known issues to v4l2-apps /tmp/newpatches/hg_hvr-1600-alsa-2_02.patch with cs=a631e089c9d6 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_03.patch with cs=a20a6f8ebf42 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_04.patch with cs=f576485071d3 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_05.patch with cs=605c1f7fed3c Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_06.patch with cs=cb267593943f Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_07.patch with cs=749aa3ccbb84 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_08.patch with cs=4ea6a2a3b501 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_09.patch with cs=58c37088f6a6 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_10.patch with cs=7b6e737ddb79 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_11.patch with cs=6bc4dc4993f7 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_12.patch with cs=e47b8ea0c818 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_13.patch with cs=95df6a4cce66 Ok. /tmp/newpatches/hg_hvr-1600-alsa-2_14.patch with cs=355c08546c21 Ok. Diffstat of the imported series: linux/drivers/media/video/cx18/Kconfig | 11 linux/drivers/media/video/cx18/Makefile |2 linux/drivers/media/video/cx18/cx18-alsa-main.c | 370 - linux/drivers/media/video/cx18/cx18-alsa-mixer.c | 191 linux/drivers/media/video/cx18/cx18-alsa-mixer.h | 23 linux/drivers/media/video/cx18/cx18-alsa-pcm.c | 407 +- linux/drivers/media/video/cx18/cx18-alsa-pcm.h | 27 linux/drivers/media/video/cx18/cx18-alsa.c | 606 +++ linux/drivers/media/video/cx18/cx18-alsa.h | 59 + linux/drivers/media/video/cx18/cx18-driver.c | 44 + linux/drivers/media/video/cx18/cx18-driver.h | 10 linux/drivers/media/video/cx18/cx18-fileops.c|6 linux/drivers/media/video/cx18/cx18-fileops.h|3 linux/drivers/media/video/cx18/cx18-mailbox.c| 16 linux/drivers/media/video/cx18/cx18-streams.c|2 15 files changed, 1429 insertions(+), 348 deletions(-) /tmp/newpatches/hg_hvr-1600-alsa-2_01.patch: cx18-alsa: Initial non-working cx18-alsa files ERROR: need consistent spacing around '+' (ctx:WxV) #124: FILE: linux/drivers/media/video/cx18/cx18-alsa-mixer.c:95: + uinfo-value.integer.max = +8; ^ total: 1 errors, 0 warnings, 579 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_02.patch: cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss /tmp/newpatches/hg_hvr-1600-alsa-2_04.patch: cx18: make it so cx18-alsa-main.c compiles WARNING: line over 80 characters #44: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:44: +#define CX18_DEBUG_ALSA_INFO(fmt, arg...) printk(KERN_INFO %s: fmt, cx18-alsa, ## arg) WARNING: printk() should include KERN_ facility level #89: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:254: + printk(cx18-alsa: drv was null\n); total: 0 errors, 2 warnings, 74 lines checked /tmp/newpatches/hg_hvr-1600-alsa-2_06.patch: cx18: overhaul ALSA PCM device handling so it works WARNING: externs should be avoided in .c files #41: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:40: +extern int cx18_alsa_debug; WARNING: externs should be avoided in .c files #50: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:49: +void cx18_alsa_announce_pcm_data(struct snd_cx18_card *cxsc, u8 *pcm_data, WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #53: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:52: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #162: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:164: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version to which it is merged #169: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:171: +#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16) WARNING: LINUX_VERSION_CODE should be avoided, code should be for the
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following changeset: 01/01: gspca - include: Fix compile errors with kernels 2.6.25. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=7f4a47d55f36 linux/drivers/media/video/gspca/gspca.h |1 + linux/drivers/media/video/gspca/sn9c20x.c |1 - linux/drivers/media/video/gspca/stv06xx/stv06xx.h |1 - v4l/compat.h |4 4 files changed, 5 insertions(+), 2 deletions(-) Thanks. -- 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. No problem. I will take care of these tonight (some of them are unrelated to my changes but happened to appear in the diff so they got flagged). Also, I am tempted to set the cx18 alsa driver to only work for kernels 2.6.25, so that I don't need any of the PCM lock changes, which are totally unvalidated and not needed by the customer. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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
[PATCH -next] radio/si470x: #include sched.h
From: Randy Dunlap randy.dun...@oracle.com Driver needs to #include sched.h: drivers/media/radio/si470x/radio-si470x-common.c:452: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function) drivers/media/radio/si470x/radio-si470x-common.c:452: error: implicit declaration of function 'signal_pending' drivers/media/radio/si470x/radio-si470x-common.c:452: error: implicit declaration of function 'schedule' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/radio/si470x/radio-si470x.h |1 + 1 file changed, 1 insertion(+) --- linux-next-20091214.orig/drivers/media/radio/si470x/radio-si470x.h +++ linux-next-20091214/drivers/media/radio/si470x/radio-si470x.h @@ -29,6 +29,7 @@ #include linux/kernel.h #include linux/module.h #include linux/init.h +#include linux/sched.h #include linux/slab.h #include linux/smp_lock.h #include linux/input.h -- 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
problems compiling webcam driver
Hello. I have modified the t613 driver to support a new sensor (code 0x0802), and I am now trying to prepare a patch to submit. The problem is that now that I started to work with the driver again, I started to get this error message... Does anybody know what is this about? I already tried to switch from the 2.6.31 kernel to the 2.6.32, but the same happened. [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, SerialNumber=0 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam [ 1525.026054] usb 6-2: Manufacturer: TASCORP [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata [ 1525.072918] gspca_main: Unknown symbol video_devdata [ 1525.073060] gspca_main: disagrees about version of symbol video_unregister_device [ 1525.073062] gspca_main: Unknown symbol video_unregister_device [ 1525.073118] gspca_main: disagrees about version of symbol video_register_device [ 1525.073119] gspca_main: Unknown symbol video_register_device [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add [ 1525.073731] gspca_t613: Unknown symbol gspca_debug [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect [ 1525.073931] gspca_t613: Unknown symbol gspca_resume [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend see you, ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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] Document the videobuf layer
Hi Jon,
You probably lost my feedback.
I've added some time ago a videobuf description at
Documentation/video4linux/v4l2-framework.txt.
It is probably better to have it as a separate document like what you've
proposed,
so, could you please drop the duplicated information that is there and move any
missing info that might not be on your new doc?
Thanks,
Mauro.
Jonathan Corbet wrote:
I've taken the liberty of dropping this into my docs-next tree, and
will send it upward unless there are objections. Hopefully it's
useful...
jon
---
V4L2: Add a document describing the videobuf layer
Videobuf is a moderately complex API which most V4L2 drivers should use,
but its documentation is...sparse. This document attempts to improve the
situation.
Signed-off-by: Jonathan Corbet cor...@lwn.net
diff --git a/Documentation/video4linux/videobuf
b/Documentation/video4linux/videobuf
new file mode 100644
index 000..4e21ea7
--- /dev/null
+++ b/Documentation/video4linux/videobuf
@@ -0,0 +1,341 @@
+An introduction to the videobuf layer
+Jonathan Corbet cor...@lwn.net
+Current as of 2.6.32
+
+The videobuf layer functions as a sort of glue layer between a V4L2 driver
+and user space. It handles the allocation and management of buffers for
+the storage of video frames. There is a set of functions which can be used
+to implement many of the standard POSIX I/O system calls, including read(),
+poll(), and, happily, mmap(). Another set of functions can be used to
+implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
+including buffer allocation, queueing and dequeueing, and streaming
+control. Using videobuf imposes a few design decisions on the driver
+author, but the payback comes in the form of reduced code in the driver and
+a consistent implementation of the V4L2 user-space API.
+
+Buffer types
+
+Not all video devices use the same kind of buffers. In fact, there are (at
+least) three common variations:
+
+ - Buffers which are scattered in both the physical and (kernel) virtual
+ address spaces. All user-space buffers are like this, but it makes
+ great sense to allocate kernel-space buffers this way as well when it is
+ possible. Unfortunately, it is not always possible; working with this
+ kind of buffer normally requires hardware which can do scatter/gather
+ DMA operations.
+
+ - Buffers which are physically scattered, but which are virtually
+ contiguous; buffers allocated with vmalloc(), in other words. These
+ buffers are just as hard to use for DMA operations, but they can be
+ useful in situations where DMA is not available but virtually-contiguous
+ buffers are convenient.
+
+ - Buffers which are physically contiguous. Allocation of this kind of
+ buffer can be unreliable on fragmented systems, but simpler DMA
+ controllers cannot deal with anything else.
+
+Videobuf can work with all three types of buffers, but the driver author
+must pick one at the outset and design the driver around that decision.
+
+Data structures, callbacks, and initialization
+
+Depending on which type of buffers are being used, the driver should
+include one of the following files:
+
+media/videobuf-dma-sg.h/* Physically scattered */
+media/videobuf-vmalloc.h /* vmalloc() buffers*/
+media/videobuf-dma-contig.h/* Physically contiguous */
+
+The driver's data structure describing a V4L2 device should include a
+struct videobuf_queue instance for the management of the buffer queue,
+along with a list_head for the queue of available buffers. There will also
+need to be an interrupt-safe spinlock which is used to protect (at least)
+the queue.
+
+The next step is to write four simple callbacks to help videobuf deal with
+the management of buffers:
+
+struct videobuf_queue_ops {
+ int (*buf_setup)(struct videobuf_queue *q,
+ unsigned int *count, unsigned int *size);
+ int (*buf_prepare)(struct videobuf_queue *q,
+struct videobuf_buffer *vb,
+enum v4l2_field field);
+ void (*buf_queue)(struct videobuf_queue *q,
+ struct videobuf_buffer *vb);
+ void (*buf_release)(struct videobuf_queue *q,
+ struct videobuf_buffer *vb);
+};
+
+buf_setup() is called early in the I/O process, when streaming is being
+initiated; its purpose is to tell videobuf about the I/O stream. The count
+parameter will be a suggested number of buffers to use; the driver should
+check it for rationality and adjust it if need be. As a practical rule, a
+minimum of two buffers are needed for proper streaming, and there is
+usually a maximum (which cannot exceed 32) which makes sense for each
+device. The size parameter should be set to the expected (maximum) size
+for each frame of data.
+
+Each buffer (in the form of a struct
Re: problems compiling webcam driver
Hi, You have to unload the all the old modules before loading the new ones: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#First_Use:_Out_with_the_Old.2C_In_with_the_New otherwise you will get that type of errors. Regards, Paulo 2009/12/14 Nicolau Werneck nwern...@gmail.com: Hello. I have modified the t613 driver to support a new sensor (code 0x0802), and I am now trying to prepare a patch to submit. The problem is that now that I started to work with the driver again, I started to get this error message... Does anybody know what is this about? I already tried to switch from the 2.6.31 kernel to the 2.6.32, but the same happened. [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, SerialNumber=0 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam [ 1525.026054] usb 6-2: Manufacturer: TASCORP [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata [ 1525.072918] gspca_main: Unknown symbol video_devdata [ 1525.073060] gspca_main: disagrees about version of symbol video_unregister_device [ 1525.073062] gspca_main: Unknown symbol video_unregister_device [ 1525.073118] gspca_main: disagrees about version of symbol video_register_device [ 1525.073119] gspca_main: Unknown symbol video_register_device [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add [ 1525.073731] gspca_t613: Unknown symbol gspca_debug [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect [ 1525.073931] gspca_t613: Unknown symbol gspca_resume [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend see you, ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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 -- 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: problems compiling webcam driver
Check that videodev.ko is the last one. Are you compiling vanilla gspca drivers from the kernel? or the mercuarial version? On Mon, Dec 14, 2009 at 2:17 PM, Nicolau Werneck nwern...@gmail.com wrote: Hello. I have modified the t613 driver to support a new sensor (code 0x0802), and I am now trying to prepare a patch to submit. The problem is that now that I started to work with the driver again, I started to get this error message... Does anybody know what is this about? I already tried to switch from the 2.6.31 kernel to the 2.6.32, but the same happened. [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, SerialNumber=0 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam [ 1525.026054] usb 6-2: Manufacturer: TASCORP [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata [ 1525.072918] gspca_main: Unknown symbol video_devdata [ 1525.073060] gspca_main: disagrees about version of symbol video_unregister_device [ 1525.073062] gspca_main: Unknown symbol video_unregister_device [ 1525.073118] gspca_main: disagrees about version of symbol video_register_device [ 1525.073119] gspca_main: Unknown symbol video_register_device [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add [ 1525.073731] gspca_t613: Unknown symbol gspca_debug [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect [ 1525.073931] gspca_t613: Unknown symbol gspca_resume [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend see you, ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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 -- 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] Document the videobuf layer
On Mon, 14 Dec 2009 15:36:08 -0200 Mauro Carvalho Chehab mche...@infradead.org wrote: It is probably better to have it as a separate document like what you've proposed, so, could you please drop the duplicated information that is there and move any missing info that might not be on your new doc? Yes, I can certainly do that. Will prepare a new patch, but it might take a day or two. jon -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Mon Dec 14 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13690:2dfce98fc6dc gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-armv5-ixp: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: WARNINGS linux-2.6.32-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-mips: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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, Forgive about the previous pull request and please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 3 changesets: 01/03: gspca - include: Fix compile errors with kernels 2.6.25. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=696f668232b3 02/03: gspca - sunplus: Add webcam 052b:1507. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=40f9ad7c1cec 03/03: gspca - main: Set the current frame pointer when first qbuf. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=bdc9ee6ae5f2 Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/gspca.c |2 ++ drivers/media/video/gspca/gspca.h |1 + drivers/media/video/gspca/sn9c20x.c |1 - drivers/media/video/gspca/stv06xx/stv06xx.h |1 - drivers/media/video/gspca/sunplus.c |1 + 6 files changed, 5 insertions(+), 2 deletions(-) Thanks. -- 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
scan/scan-s2 doesn't tune, but dvbtune does?
I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S). My test satellite is AMC1 103W, the Pentagon Channel tp. This is probably some simple user error on my part, but I can't figure it out. I have a Corotor II with polarity changed via serial command to an external IRD. C/Ku is switched by 22KHz tone, voltage is always 18V. Ku is with tone off, C with tone on. Speaking of which, is there a way to manually set the tone from the arguments on the scan utilities? Here's what I've tried and the results: $ ./scan-s2 -a 0 -v -o zap -l 10750 INIT API major 5, minor 0 scanning INIT using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S 1210 H 2000 AUTO AUTO AUTO initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO -- Using DVB-S tune to: 12100:h:0:2 DVB-S IF freq is 135 tuning status == 0x03 tuning status == 0x01 tuning status == 0x03 tuning status == 0x01 tuning status == 0x03 tuning status == 0x00 tuning status == 0x01 tuning status == 0x03 tuning status == 0x00 tuning status == 0x00 WARNING: tuning failed!!! tune to: 12100:h:0:2 (tuning failed) DVB-S IF freq is 135 tuning status == 0x03 tuning status == 0x01 tuning status == 0x00 tuning status == 0x00 ...snip... Same thing happens if I use just 'scan' and not 'scan-s2.' If I use dvbtune, it works though.. $ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m Using DVB card Conexant CX24116/CX24118 tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Bit error rate: 0 Signal strength: 51648 SNR: 26215 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|) Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|) The tuning file 'INIT' contains only the following line: S 1210 H 2000 AUTO I'm using v4l-dvb drivers from the main repo as of about a week ago. I am running kernel 2.6.32 on Debian testing. Any help is appreciated ..and hopefully it's just a simple flub on my part! --Mike -- 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: [PULL] soc-camera and mediabus
On Mon, 14 Dec 2009, Jonathan Cameron wrote:
Hi All,
3) it would be interesting to patch the other sensor drivers to be
compatible
with soc_camera (mt9v011/ov7670);
Well, this could be done, yes, but does it make sense to do this blindly
without any hardware to test? I would rather add such conversions on a
one-by-one basis as need arises.
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet. For reference, a quick and
dirty
cut of the patch is below. Some thought is needed on how to deal with the
sections
that currently need to be different for the soc-camera and non soc camera
uses.
(mainly the registration code in probe).
Look at my patch for mt9t031. First you do not have to fail if
client-dev.platform_data == NULL. You have to look at the bridge driver,
that's currently working with ov7670. If it is not setting platform_data,
you can use it to detect whether you're in soc-camera environment or not.
Otherwise, if the bridge driver were also using that pointer, we would
have to come up with a ov7670-specific struct to be linked from that
pointer. I was actually thinking about a way to pass soc-camera data to
client drivers in a way, that would not imped non soc-camera use. So, how
about:
I soc-camera environment
1. platform defines a
static struct ov7670_platform_data ov7670 = {
.link = ov7670_link,
};
2. and a
static struct soc_camera_link ov7670_link = {
.client_data = ov7670,
};
3. soc-camera core gets ov7670_link in its probe, same as this is done
now, then it does
icl-icd = icd;
icl-board_info-platform_data = icl-client_data;
subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
icl-module_name, icl-board_info, NULL);
4. ov7670 probe is called with client platform data pointing to its own
data:
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov7670_platform_data *pdata = client-dev.platform_data;
struct soc_camera_link *icl = pdata-link;
struct soc_camera_device *icd;
if (icl)
icd = icl-icd;
II Non soc-camera environment
1. the bridge driver fills in sensor data and does
struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
ov7670_pdata-... = ...;
board_info-platform_data = ov7670_pdata;
subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
module_name, board_info, NULL);
2. ov7670_probe() gets called and finds its data as above, but without an
soc-camera link this time.
The advantage of the above is, that each client driver is free to define
its own platform data struct, and for soc-camera it only has to provide
one pointer in it. The ugly side is the cross-referencing between I.1. and
I.2. above.
Alternatively we could agree, that all client drivers get in their i2c
client platform data a standard struct with only pointers in it to client
data and to various bridging models:
struct v4l2_client {
void *client;
struct soc_camera_link *icl;
struct int_device_link *int;
...
};
or a bit more hidden
struct v4l2_client {
void *client;
void *bridge_data;
enum V4L2_BRIDGE_TYPE bridge_type;
};
On another note, does anyone have an objection to making the set_bus_param
function optional? At the moment we are adding null functions for those
devices that can't actually change anything which seems a little pointless.
Yes, it can.
Jonathan
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..e57c3b5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#include media/soc_camera.h
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
@@ -545,7 +546,7 @@ static struct ov7670_format_struct {
.bpp= 1
},
};
-#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
+
/*
@@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int
hstart, int hstop,
return ret;
}
+static enum v4l2_mbus_pixelcode ov7670_codes[] = {
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_RGB565_2X8_LE,
+};
-static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
+static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum
v4l2_mbus_pixelcode *code)
{
- struct ov7670_format_struct *ofmt;
-
- if (fmt-index = N_OV7670_FMTS)
+ if (index = ARRAY_SIZE(ov7670_codes))
return -EINVAL;
- ofmt = ov7670_formats + fmt-index;
- fmt-flags = 0;
- strcpy(fmt-description, ofmt-desc);
- fmt-pixelformat = ofmt-pixelformat;
+
budget_ci: BUG: unable to handle kernel paging request
Hi, a current build of http://mercurial.intuxication.org/hg/s2-liplianin (changeset 13860:1944670e9fbe) yields a kernel paging error when inserting budget_ci on a Ubuntu 9.10 system (2.6.31-16) with three S2-3200 and one Tevii 470 cards: Dec 14 23:35:54 tvserver kernel: [0.00] Initializing cgroup subsys cpuset Dec 14 23:35:54 tvserver kernel: [0.00] Initializing cgroup subsys cpu Dec 14 23:35:54 tvserver kernel: [0.00] Linux version 2.6.31-16-generic (bui...@vernadsky) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #52-Ubuntu SMP Thu Dec 3 22:00:22 UTC 2009 (Ubuntu 2.6.31-16.52-generic) Dec 14 23:35:54 tvserver kernel: [0.00] KERNEL supported cpus: Dec 14 23:35:54 tvserver kernel: [0.00] Intel GenuineIntel Dec 14 23:35:54 tvserver kernel: [0.00] AMD AuthenticAMD Dec 14 23:35:54 tvserver kernel: [0.00] NSC Geode by NSC Dec 14 23:35:54 tvserver kernel: [0.00] Cyrix CyrixInstead Dec 14 23:35:54 tvserver kernel: [0.00] Centaur CentaurHauls Dec 14 23:35:54 tvserver kernel: [0.00] Transmeta GenuineTMx86 Dec 14 23:35:54 tvserver kernel: [0.00] Transmeta TransmetaCPU Dec 14 23:35:54 tvserver kernel: [0.00] UMC UMC UMC UMC Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-provided physical RAM map: Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: - 0009fc00 (usable) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 0009fc00 - 000a (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 000e7000 - 0010 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 0010 - 7ffb (usable) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 7ffb - 7ffc (ACPI data) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 7ffc - 7fff (ACPI NVS) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: 7fff - 8000 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: fec0 - fec01000 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: fee0 - fef0 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-e820: fff8 - 0001 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] DMI present. Dec 14 23:35:54 tvserver kernel: [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. Dec 14 23:35:54 tvserver kernel: [0.00] e820 update range: - 0001 (usable) == (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] last_pfn = 0x7ffb0 max_arch_pfn = 0x10 Dec 14 23:35:54 tvserver kernel: [0.00] MTRR default type: uncachable Dec 14 23:35:54 tvserver kernel: [0.00] MTRR fixed ranges enabled: Dec 14 23:35:54 tvserver kernel: [0.00] 0-9 write-back Dec 14 23:35:54 tvserver kernel: [0.00] A-E uncachable Dec 14 23:35:54 tvserver kernel: [0.00] F-F write-protect Dec 14 23:35:54 tvserver kernel: [0.00] MTRR variable ranges enabled: Dec 14 23:35:54 tvserver kernel: [0.00] 0 base 00 mask FF8000 write-back Dec 14 23:35:54 tvserver kernel: [0.00] 1 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 2 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 3 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 4 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 5 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 6 disabled Dec 14 23:35:54 tvserver kernel: [0.00] 7 disabled Dec 14 23:35:54 tvserver kernel: [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Dec 14 23:35:54 tvserver kernel: [0.00] Scanning 0 areas for low memory corruption Dec 14 23:35:54 tvserver kernel: [0.00] modified physical RAM map: Dec 14 23:35:54 tvserver kernel: [0.00] modified: - 0001 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 0001 - 0009fc00 (usable) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 0009fc00 - 000a (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 000e7000 - 0010 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 0010 - 7ffb (usable) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 7ffb - 7ffc (ACPI data) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 7ffc - 7fff (ACPI NVS) Dec 14 23:35:54 tvserver kernel: [0.00] modified: 7fff - 8000 (reserved) Dec 14 23:35:54 tvserver kernel: [0.00] modified: fec0 -
[PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following changeset: 01/01: Add Prof 7500 DVB-S2 USB card http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=a05b1d723aac dvb-usb/dw2102.c | 94 ++- frontends/stv0900.h |2 + frontends/stv0900_core.c | 87 +++ frontends/stv0900_priv.h | 11 + frontends/stv0900_reg.h |6 +++ frontends/stv0900_sw.c | 44 ++ 6 files changed, 226 insertions(+), 18 deletions(-) Thanks, Igor -- 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- gspca: added chipset revision sensor
Hello,
Added extra chipset revision (sensor) to fix camera zc0301 with ID:
0ac8:301b .
Since i own one of this cameras fixed and tested it.
Best Regards,
Luis Maia
-
diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c2009-12-15
02:42:13.0 +
@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14},/* CS2102K */
{0x8400, 0x15},/* TAS5130K */
+{0xe400, 0x15},
};
static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
-{USB_DEVICE(0x0ac8, 0x301b)},
+{USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info = SENSOR_TAS5130C_VF0250},
{USB_DEVICE(0x0ac8, 0x307b)},
diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c 2009-12-15
02:42:13.0 +
@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14}, /* CS2102K */
{0x8400, 0x15}, /* TAS5130K */
+ {0xe400, 0x15},
};
static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
- {USB_DEVICE(0x0ac8, 0x301b)},
+ {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info = SENSOR_TAS5130C_VF0250},
{USB_DEVICE(0x0ac8, 0x307b)},
Re: [PULL] soc-camera and mediabus
On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
On Mon, 14 Dec 2009, Jonathan Cameron wrote:
Hi All,
3) it would be interesting to patch the other sensor drivers to be
compatible
with soc_camera (mt9v011/ov7670);
Well, this could be done, yes, but does it make sense to do this blindly
without any hardware to test? I would rather add such conversions on a
one-by-one basis as need arises.
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet. For reference, a quick and
dirty
cut of the patch is below. Some thought is needed on how to deal with the
sections
that currently need to be different for the soc-camera and non soc camera
uses.
(mainly the registration code in probe).
Look at my patch for mt9t031. First you do not have to fail if
client-dev.platform_data == NULL. You have to look at the bridge driver,
that's currently working with ov7670. If it is not setting platform_data,
you can use it to detect whether you're in soc-camera environment or not.
Otherwise, if the bridge driver were also using that pointer, we would
have to come up with a ov7670-specific struct to be linked from that
pointer. I was actually thinking about a way to pass soc-camera data to
client drivers in a way, that would not imped non soc-camera use. So, how
about:
I soc-camera environment
1. platform defines a
static struct ov7670_platform_data ov7670 = {
.link = ov7670_link,
};
2. and a
static struct soc_camera_link ov7670_link = {
.client_data = ov7670,
};
3. soc-camera core gets ov7670_link in its probe, same as this is done
now, then it does
icl-icd = icd;
icl-board_info-platform_data = icl-client_data;
subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
icl-module_name, icl-board_info, NULL);
4. ov7670 probe is called with client platform data pointing to its own
data:
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov7670_platform_data *pdata = client-dev.platform_data;
struct soc_camera_link *icl = pdata-link;
struct soc_camera_device *icd;
if (icl)
icd = icl-icd;
II Non soc-camera environment
1. the bridge driver fills in sensor data and does
struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
ov7670_pdata-... = ...;
board_info-platform_data = ov7670_pdata;
subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
module_name, board_info, NULL);
2. ov7670_probe() gets called and finds its data as above, but without an
soc-camera link this time.
The advantage of the above is, that each client driver is free to define
its own platform data struct, and for soc-camera it only has to provide
one pointer in it. The ugly side is the cross-referencing between I.1. and
I.2. above.
Alternatively we could agree, that all client drivers get in their i2c
client platform data a standard struct with only pointers in it to client
data and to various bridging models:
struct v4l2_client {
void *client;
struct soc_camera_link *icl;
struct int_device_link *int;
...
};
or a bit more hidden
struct v4l2_client {
void *client;
void *bridge_data;
enum V4L2_BRIDGE_TYPE bridge_type;
};
Before this goes too far let me just say that I will NAK any attempt in this
direction. Subdevice drivers must eventually be completely independent from
bridge driver. The same driver should work out of the box for soc-camera,
gspca, omap3, davinci, saa7134 and whatever other bridge driver is out there.
Having bridge-specific code in a sub-device driver will be a disaster in the
long run. Well, we've seen what happens when you do it that way.
As far as I know the only soc-dependency left now is for bus configuration.
Proposals were made some time ago and we should pick that up again and remove
that last dependency.
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: [PATCH - v1 3/6] V4L-vpfe-capture-Adding ISIF driver for DM365 - source
On Thursday 10 December 2009 18:00:26 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
This is the source file for ISIF driver for DM365. This has comments
incorporated from
initial version.
ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is
tested for
YUV capture from TVP514x driver. This patch contains the header files
required for
this driver. The name of the file is changed to reflect the name of IP.
Reviewed-by: Nori, Sekhar nsek...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/isif.c | 1498
1 files changed, 1498 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/isif.c
diff --git a/drivers/media/video/davinci/isif.c
b/drivers/media/video/davinci/isif.c
new file mode 100644
index 000..916afab
--- /dev/null
+++ b/drivers/media/video/davinci/isif.c
@@ -0,0 +1,1498 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * This is the isif hardware module.
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *2) Add support for control ioctl
+ */
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/io.h
+#include linux/videodev2.h
+#include linux/clk.h
+
+#include mach/mux.h
+
+#include media/davinci/isif.h
+#include media/davinci/vpss.h
+
+#include isif_regs.h
+#include ccdc_hw_device.h
+
+/* Defauts for module configuation paramaters */
Typos: 'Defaults', 'configuration' and 'parameters'.
BTW: Please comment somewhere what 'ISIF' stands for!
+static struct isif_config_params_raw isif_config_defaults = {
+ .linearize = {
+ .en = 0,
+ .corr_shft = ISIF_NO_SHIFT,
+ .scale_fact = {1, 0},
+ },
+ .df_csc = {
+ .df_or_csc = 0,
+ .csc = {
+ .en = 0,
+ },
+ },
+ .dfc = {
+ .en = 0,
+ },
+ .bclamp = {
+ .en = 0,
+ },
+ .gain_offset = {
+ .gain = {
+ .r_ye = {1, 0},
+ .gr_cy = {1, 0},
+ .gb_g = {1, 0},
+ .b_mg = {1, 0},
+ },
+ },
+ .culling = {
+ .hcpat_odd = 0xff,
+ .hcpat_even = 0xff,
+ .vcpat = 0xff,
+ },
+ .compress = {
+ .alg = ISIF_ALAW,
+ },
+};
+
+/* ISIF operation configuration */
+static struct isif_oper_config {
+ struct device *dev;
+ enum vpfe_hw_if_type if_type;
+ struct isif_ycbcr_config ycbcr;
+ struct isif_params_raw bayer;
+ enum isif_data_pack data_pack;
+ /* Master clock */
+ struct clk *mclk;
+ /* ISIF base address */
+ void __iomem *base_addr;
+ /* ISIF Linear Table 0 */
+ void __iomem *linear_tbl0_addr;
+ /* ISIF Linear Table 1 */
+ void __iomem *linear_tbl1_addr;
+} isif_cfg = {
+ .ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = ISIF_WIN_NTSC,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
+ },
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = ISIF_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = {1, 0},
+ .gr_cy = {1, 0},
+ .gb_g = {1, 0},
+ .b_mg = {1, 0},
+ },
+ .cfa_pat = ISIF_CFA_PAT_MOSAIC,
+ .data_msb = ISIF_BIT_MSB_11,
+ .config_params = {
+ .data_shift = ISIF_NO_SHIFT,
+ .col_pat_field0 = {
+
