Re: Fwd: Compro S300 - ZL10313
On Samstag, 2. Januar 2010, Theunis Potgieter wrote: > 2010/1/2 JD Louw : > > On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: > >> 2010/1/1 JD Louw : > >> > On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: > >> >> Hi mailing list, > >> >> > >> >> I have a problem with my Compro S300 pci card under Linux 2.6.32. > >> >> > >> >> I cannot tune with this card and STR/SNRA is very bad compared to my > >> >> Technisat SkyStar 2 pci card, connected to the same dish. > >> >> > >> >> I have this card and are willing to run tests, tested drivers etc to > >> >> make this work. > >> >> > >> >> I currently load the module saa7134 with options: card=169 > >> >> > >> >> I enabled some debug parameters on the saa7134, not sure what else I > >> >> should enable. Please find my dmesg log attached. > >> >> > >> >> lsmod shows : > >> >> > >> >> # lsmod > >> >> Module Size Used by > >> >> zl10039 6268 2 > >> >> mt312 12048 2 > >> >> saa7134_dvb41549 11 > >> >> saa7134 195664 1 saa7134_dvb > >> >> nfsd 416819 11 > >> >> videobuf_dvb8187 1 saa7134_dvb > >> >> dvb_core 148140 1 videobuf_dvb > >> >> ir_common 40625 1 saa7134 > >> >> v4l2_common21544 1 saa7134 > >> >> videodev 58341 2 saa7134,v4l2_common > >> >> v4l1_compat24473 1 videodev > >> >> videobuf_dma_sg17830 2 saa7134_dvb,saa7134 > >> >> videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg > >> >> tveeprom 12550 1 saa7134 > >> >> thermal20547 0 > >> >> processor 54638 1 > >> >> > >> >> # uname -a > >> >> Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 > >> >> Pentium III (Coppermine) GenuineIntel GNU/Linux > >> >> > >> >> Thanks, > >> >> Theunis > >> > > >> > Hi, > >> > > >> > It's probably the GPIO settings that are wrong for your SAA7133 based > >> > card revision. See > >> > http://osdir.com/ml/linux-media/2009-06/msg01256.html for an > >> > explanation. For quick confirmation check if you have 12V - 20V DC > >> > going to your LNB. The relevant lines of code is in > >> > ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: > >> > > >> > case SAA7134_BOARD_VIDEOMATE_S350: > >> > dev->has_remote = SAA7134_REMOTE_GPIO; > >> > saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0x8000, 0x8000); > >> > saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000); > >> > break; > >> > >> Hi thanks for the hint. I changed it to the following: > >> > >> case SAA7134_BOARD_VIDEOMATE_S350: > >> dev->has_remote = SAA7134_REMOTE_GPIO; > >> saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0xc000, 0xc000); > >> saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xc000, 0xc000); > >> break; > >> > >> I now get the same SNR as on my skystar2 card, signal is still > >> indicating 17% where as the skystar2 would show 68%. At least I'm > >> getting a LOCK on channels :) > >> > >> Thanks! > >> > >> > Looking at your log, at least the demodulator and tuner is responding > >> > correctly. You can see this by looking at the i2c traffic addressed to > >> > 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my > >> > working SAA7130 based card. > >> > > >> > Regards > >> > JD > > > > Hi, > > > > Just to clarify, can you now watch channels? > > Hi Jan, yes I can watch channels on Vivid bouquet, some of which are > FTA channels. Here is some channels I can get a lock and a picture on > vdr: > > GodCh;GodCh:11674:vC56M2O0S0:S68.5E:26652:0:0:0:0:110:73:3:0 > ASTV;ASTV:11674:vC56M2O0S0:S68.5E:26652:0:0:0:0:111:73:3:0 > > > At the moment the signal strength measurement is a bit whacked, so don't > > worry too much about it. I also get the 75%/17% figures you mentioned > > when tuning to strong signals. The figure is simply reported wrongly: > > even weaker signals should tune fine. If you want you can have a look in > > ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at > > mt312_read_signal_strength(). > > > > Also, if you have a multimeter handy, can you confirm that the > > 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for > > this. I've already tested this on my older card with no ill effect. > > I will try and do this as soon as possible. > Was there any worth while information in the ZL10313 documentation > that could assist in setting the correct parameters for my Compro > S300? > I added the support for ZL10313 to mt312 driver. And at least for my card, the documentation of ZL10313 did help only a bit for setting GPIOs correctly. The most important step was tracing copper on the board, and having a look at how the windows driver sets the gpio lines. Have a look at my results: http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_DVB- S_Pro_(A700)#GPIO_table Most important pin to get correct is the one that resets demod, but you got it right it
Re: Lenovo compact webcam 17ef:4802
On Sun, 03 Jan 2010 19:51:37 -0500 Bill Whiting wrote: > I have not been able to get an image from a Lenovo webcam under > Fedora 11. It reports to the kernel with USB id 17ef:4802 as below: > > kernel: usb 1-3: new high speed USB device using ehci_hcd and > address 9 kernel: usb 1-3: New USB device found, idVendor=17ef, > idProduct=4802 kernel: usb 1-3: New USB device strings: Mfr=1, > Product=2, SerialNumber=0 kernel: usb 1-3: Product: Lenovo USB Webcam > kernel: usb 1-3: Manufacturer: Primax > kernel: usb 1-3: configuration #1 chosen from 1 choice > kernel: gspca: probing 17ef:4802 > kernel: vc032x: check sensor header 20 > kernel: vc032x: Sensor ID 143a (3) > kernel: vc032x: Find Sensor MI1310_SOC > kernel: gspca: probe ok [snip] Hello Bill, I don't know which version of gspca is included in your kernel. First, do you use the v4l library when running cheese or skype? Then, may you get the last video stuff from LinuxTv.org and check if it works? Regards. -- 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: Lenovo compact webcam 17ef:4802
The gspca module is provided as part of the kernel. The kernel version is 2.6.30-10 The libv4l version is 0.6.3-1 Is there a way that I can display the version of gspca? I looked in dmesg and /var/log/messages but didn't find a version listed. I think cheese may be using gstreamer. How can I confirm whether cheese or skype are using v4l? //Bill On 01/04/2010 04:19 AM, Jean-Francois Moine wrote: On Sun, 03 Jan 2010 19:51:37 -0500 Bill Whiting wrote: I have not been able to get an image from a Lenovo webcam under Fedora 11. It reports to the kernel with USB id 17ef:4802 as below: kernel: usb 1-3: new high speed USB device using ehci_hcd and address 9 kernel: usb 1-3: New USB device found, idVendor=17ef, idProduct=4802 kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb 1-3: Product: Lenovo USB Webcam kernel: usb 1-3: Manufacturer: Primax kernel: usb 1-3: configuration #1 chosen from 1 choice kernel: gspca: probing 17ef:4802 kernel: vc032x: check sensor header 20 kernel: vc032x: Sensor ID 143a (3) kernel: vc032x: Find Sensor MI1310_SOC kernel: gspca: probe ok [snip] Hello Bill, I don't know which version of gspca is included in your kernel. First, do you use the v4l library when running cheese or skype? Then, may you get the last video stuff from LinuxTv.org and check if it works? Regards. -- 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: DVBWorld DVB-S2 2005 PCI-Express Card
I have a very similar problem with DVBWorld 2006 DVB-S2 card. The v4l-dvb ( freshly pulled ) compiles and loads, firmware is loaded, but when I actually try to use it ( dvbstream commands ) the following appears in /var/log/messages: Jan 4 18:30:24 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:24 november kernel: ds3000_readreg: reg=0xd1(error=-1) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_readreg: reg=0xd1(error=-1) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err == -1, reg == 0xf9, value == 0x04) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_readreg: reg=0xf8(error=-1) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err == -1, reg == 0x03, value == 0x12) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_tuner_readreg: reg=0x3d(error=-1) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err == -1, reg == 0x03, value == 0x12) Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur Jan 4 18:30:25 november kernel: ds3000_tuner_readreg: reg=0x21(error=-1) ... and many more of this. Actually I have to say I already tried DVBWorld 2006, NetUP dual DVB-S2 and TwinHan VP-1041 ( like the Technisat card ) but no success at all. DVBWorld is giving me errors like above, NetUP's driver loads but doesn't want to tune to anything, Twinhan can tune to one transponder and scan the channels but for reasons far beyond me fails to tune to anything else. DVB-T ( Leadtek WinFast ) is working for me perfectly, but DVB-S is an exercise in frustration... -- 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: cx18: Need information on SECAM-D/K problem with PVR-2100
> "Andy" == Andy Walls writes: > Sergey, > On IRC you mentioned a problem of improper detection of SECAM-D/K with > the Leadtek PVR2100 (XC2028 and CX23418) from an RF source. It was some misunderstanding, i suppose, i do not have problems with secam, i had improper detection of sound standard (and silence as result) on pal channels. Later i've found, that fully-specified std (pal-d instead of just pal) helps, so i can live with that. Anyway, logs you requested (first STATUS CARD chunk for pal, second for pal-d): cx18: Start initialization, version 1.2.0 cx18-0: Initializing card 0 cx18-0: Autodetected Leadtek WinFast PVR2100 card cx18 :01:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 cx18-0: cx23418 revision 0101 (B) cx18-0: Experimenters and photos needed for device to work well. To help, mail the ivtv-devel list (www.ivtvdriver.org). IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs tuner 1-0061: Setting mode_mask to 0x0e tuner 1-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) tuner 1-0061: tuner 0x61: Tuner type absent tuner 1-0061: Calling set_type_addr for type=71, addr=0xff, mode=0x04, config=0x tuner 1-0061: defining GPIO callback xc2028: Xcv2028/3028 init called! xc2028 1-0061: creating new instance xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner tuner 1-0061: type set to Xceive XC3028 tuner 1-0061: cx18 i2c driver #0-1 tuner I2C addr 0xc2 with type 71 used for 0x0e xc2028 1-0061: xc2028_set_config called cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB) cx18-0: Registered device video32 for encoder YUV (16 x 128 kB) cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes) cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB) cx18-0: Registered device radio0 for encoder radio cx18-0: Initialized card: Leadtek WinFast PVR2100 cx18: End initialization cx18 :01:07.0: firmware: requesting v4l-cx23418-cpu.fw cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) cx18 :01:07.0: firmware: requesting v4l-cx23418-apu.fw cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) cx18 :01:07.0: firmware: requesting v4l-cx23418-cpu.fw cx18 :01:07.0: firmware: requesting v4l-cx23418-apu.fw cx18 :01:07.0: firmware: requesting v4l-cx23418-dig.fw cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) tuner 1-0061: switching to v4l2 tuner 1-0061: tv freq set to 400.00 xc2028 1-0061: xc2028_set_analog_freq called xc2028 1-0061: generic_set_freq called xc2028 1-0061: should set frequency 40 kHz xc2028 1-0061: check_firmware called xc2028 1-0061: load_all_firmwares called xc2028 1-0061: Reading firmware xc3028-v27.fw cx18 :01:07.0: firmware: requesting xc3028-v27.fw xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 1-0061: Reading firmware type BASE F8MHZ (3), id 0, size=8718. xc2028 1-0061: Reading firmware type BASE F8MHZ MTS (7), id 0, size=8712. xc2028 1-0061: Reading firmware type BASE FM (401), id 0, size=8562. xc2028 1-0061: Reading firmware type BASE FM INPUT1 (c01), id 0, size=8576. xc2028 1-0061: Reading firmware type BASE (1), id 0, size=8706. xc2028 1-0061: Reading firmware type BASE MTS (5), id 0, size=8682. xc2028 1-0061: Reading firmware type (0), id 10007, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 10007, size=169. xc2028 1-0061: Reading firmware type (0), id 20007, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 20007, size=169. xc2028 1-0061: Reading firmware type (0), id 40007, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 40007, size=169. xc2028 1-0061: Reading firmware type (0), id 80007, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 80007, size=169. xc2028 1-0061: Reading firmware type (0), id 300e0, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 300e0, size=169. xc2028 1-0061: Reading firmware type (0), id c00e0, size=161. xc2028 1-0061: Reading firmware type MTS (4), id c00e0, size=169. xc2028 1-0061: Reading firmware type (0), id 20, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 20, size=169. xc2028 1-0061: Reading firmware type (0), id 400, size=161. xc2028 1-0061: Reading firmware type MTS (4), id 400, size=169. xc2028 1-0061: Reading firmware type D2633 DTV6 ATSC (10030), id 0, size=149. xc2028 1-0061: Reading firmware type D2620 DTV6 QAM (68), id 0, size=149. xc2028 1-0061: Reading firmware type D2633 DTV6 QAM (70), id 0, size=149. xc2028 1-0061: Reading firmware type D2620 DTV7 (88), id 0, size=149. xc2028 1-0061: Reading firmware type D2633 DTV7 (90), id 0, size=149. xc2028 1-0061: Reading firmware type D2620 DTV78 (108), id 0, size=149. xc2028 1-0061: Reading firmware type D2633 DTV78 (110), id 0, size=149. xc2028 1-0061: R
Re: [PATCH] RFC: mx27: Add soc_camera support
Hi Javier, On 1/4/10, javier Martin wrote: > Alan, > please, could you point me against which kernel version did you exactly test > this patch? It applies on current kernel from git.pengutronix.de/git/imx/linux-2.6.git > Also it would be fine to know which video sensor did you use. > I'm planning to use an OV2640 camera. > We are planning to improve this if it works. > Yes, this is the idea :) > Thank you. > You are welcome, Alan -- 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] DTV2000 H Plus
Thanks Jonathan wrote: Hi, I have that card (the J version I think) and run it on the latest version of Kubuntu - works fine, but cannot handle the analogue signal, I got it to work on analogue once, but then an upgrade came and I forgot and I haven't hd the time. Anyway for digital, Try adding to "/etc/modprobe.d/options.dpkg-bak" options cx88xx card=51 and then restart. I recomend using Me-TV. It's aussie, and simple to setup and use. Particulalry if you want to be using the computer for things other than TV. Also try Add "cx88-dvb" to /etc/modules Have a look at http://www.mythtv.org/wiki/Leadtek_DTV-2000H Cheers Jon On Sun, 3 Jan 2010 07:39:44 pm Raena Lea-Shannon wrote: > I do not seem to be able to get my DTV2000 to find a tuner. Seems to be > problem finding the card. Any suggestions would be greatly appreciated. > I am running Kubuntu Karmic 2.6.31-16-generic on AMD64 quadcore. > > I came across this Patch which seesm to be on the point > http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html > > but I do not have a cx88-cards.c file? I have compiled latest mercurial > v4l. Do I need to make an empty file cx88-cards.c? Excuse my ignorance I > am not a developer. > > I have tried to run modprobe cx88xx card=51 to no avail. > > Here is part of an mplayer, lspci and dmesg follow. > > > Selected driver: v4l2 > name: Video 4 Linux 2 input > author: Martin Olschewski > comment: first try, more to come ;-) > Selected device: UNKNOWN/GENERIC > Capabilites: video capture VBI capture device read/write streaming > supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = NTSC-443; 3 = PAL-BG; > 4 = PAL-I; 5 = PAL-DK; 6 = PAL-M; 7 = PAL-N; 8 = PAL-Nc; 9 = PAL-60; 10 > = SECAM-B; 11 = SECAM-G; 12 = SECAM-H; 13 = SECAM-DK; 14 = SECAM-L; > inputs: 0 = Composite1; 1 = Composite2; 2 = Composite3; 3 = Composite4; > > I am running Kubuntu Karmic 2.6.31-16-generic on AMD64 quadcore. I have > latest mercurial of v4l installed. > > Here is the Lspci info and dmesg etc > > 5:05.0 Network controller [0280]: Techsan Electronics Co Ltd B2C2 > FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] (rev 02) > > Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / > Technisat SkyStar2 DVB card [13d0:2103] > Flags: bus master, slow devsel, latency 64, IRQ 20 > Memory at fbff (32-bit, non-prefetchable) [size=64K] > I/O ports at ec00 [size=32] > Kernel driver in use: b2c2_flexcop_pci > Kernel modules: b2c2-flexcop-pci > > 05:06.0 Multimedia video controller [0400]: Conexant Systems, Inc. > CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) > Subsystem: LeadTek Research Inc. Device [107d:6f42] > Flags: bus master, medium devsel, latency 64, IRQ 21 > Memory at f800 (32-bit, non-prefetchable) [size=16M] > Capabilities: > Kernel driver in use: cx8800 > Kernel modules: cx8800 > > 05:06.1 Multimedia controller [0480]: Conexant Systems, Inc. > CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05) > Subsystem: LeadTek Research Inc. Device [107d:6f42] > Flags: bus master, medium devsel, latency 64, IRQ 21 > Memory at f900 (32-bit, non-prefetchable) [size=16M] > Capabilities: > Kernel driver in use: cx88_audio > Kernel modules: cx88-alsa > > 05:06.2 Multimedia controller [0480]: Conexant Systems, Inc. > CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) > Subsystem: LeadTek Research Inc. Device [107d:6f42] > Flags: bus master, medium devsel, latency 64, IRQ 10 > Memory at fa00 (32-bit, non-prefetchable) [size=16M] > Capabilities: > Kernel modules: cx8802 > > dmesg in part here: > [snip] > > [ 20.387650] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV > receiver chip loaded successfully > [ 20.390596] EDAC MC: Ver: 2.1.0 Dec 8 2009 > [ 20.392347] flexcop-pci: will use the HW PID filter. > [ 20.392351] flexcop-pci: card revision 2 > [ 20.392359] alloc irq_desc for 20 on node 0 > [ 20.392361] alloc kstat_irqs on node 0 > [ 20.392366] b2c2_flexcop_pci :05:05.0: PCI INT A -> GSI 20 > (level, low) -> IRQ 20 > [ 20.403400] EDAC amd64_edac: Ver: 3.2.0 Dec 8 2009 > [ 20.404070] EDAC amd64: This node reports that Memory ECC is > currently disabled. > [ 20.404073] EDAC amd64: bit 0x40 in register F3x44 of the > MISC_CONTROL device (:00:18.3) should be enabled > [ 20.404076] EDAC amd64: WARNING: ECC is NOT currently enabled by the > BIOS. Module will NOT be loaded. > [ 20.404077] Either Enable ECC in the BIOS, or use the > 'ecc_enable_override' parameter. > [ 20.404078] Might be a BIOS bug, if BIOS says ECC is enabled > [ 20.404078] Use of the override can cause unknown side effects. > [ 20.404541] amd64_edac: probe of :00:18.2 failed with error -22 > [ 20.425278] HDA Intel :00:14.2: PCI INT A -> GSI 16 (level, low) > -> IRQ
Re: DTV2000 H Plus issues
Samuel Rakitnican wrote: On Sun, 03 Jan 2010 09:21:21 +0100, Raena Lea-Shannon wrote: istva...@mailbox.hu wrote: On 01/02/2010 05:10 PM, Raena Lea-Shannon wrote: I have 2 TV Cards. The DTV2000 H Plus and a Technisat. The Technisat works very well. I am trying to get the DVT working for other video input devices such as VCR to make copies of old Videos and an inteface for my N95 video out. I do not seem to be able to get it to find a tuner. Seems to be problem finding the card. Any suggestions wold be greatly appreciated. This card uses an Xceive XC4000 tuner, which is not supported yet. However, a driver for the tuner chip is being developed at kernellabs.com, so the card may become supported in the future. -- [snip] That seems odd. This patch on the LinuxTv site http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html seems to be using the cx88 drivers? [...] Hi, I'm not a developer, but I think that your device uses both of these chips. cx88 is the bridge chip, while the Xceive is the tuner chip. So, both of them needs to be supported in order for a device to work properly. Please see the following link for reference: http://www.kernellabs.com/blog/?p=1045 Regards -- 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 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: CI USB
> BTW, Hauppauge's WinTV-CI looked much more promissing. > At least when I started reading whole thread about it here: > http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html > > Unfortunatelly, last Steve's note about not getting anything > (even any answer) has disappointed me fully. And because > google is quiet about any progress on it I pressume > no any docu nor driver was released later on. The whole project went badly wrong when the hardware vendor promised documentation then failed to deliver. My mistake for trusting them in the first place. I had considered running a driver reverse engineering tutorial project via kernellabs.com. Perhaps a 4 part series of writings, tools and instructions that describe how to reverse engineer USB drivers and culminates in a working skeleton driver for the WinTV CI that could be used. I doubt I could make this happen without a project sponsor so if you know any companies that would be willing to sponsor a project like this then I'd certainly be interested in helping. Regards, -- Steven Toth - 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 0/9] Feature enhancement of VPFE/CCDC Capture driver
From: Vaibhav Hiremath While adding support for AM3517/05 devices I have implemented/came-across these features/enhancement/bug-fixes for VPFE-Capture driver. Also the important change added is, to introduced "ti-media" directory for all TI devices. Vaibhav Hiremath (9): Makfile:Removed duplicate entry of davinci TVP514x:Switch to automode for querystd tvp514x: add YUYV format support Introducing ti-media directory DMx:Update board files for ti-media directory change Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile|4 +- drivers/media/video/davinci/Makefile| 17 - drivers/media/video/davinci/ccdc_hw_device.h| 110 -- drivers/media/video/davinci/dm355_ccdc.c| 1081 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 966 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2055 - drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 --- drivers/media/video/davinci/vpif_capture.c | 2168 --- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 - drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 drivers/media/video/ti-media/Kconfig| 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 drivers/media/video/ti-media/dm644x_ccdc.c | 1090 drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2067 + drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 + drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 drivers/media/video/tvp514x.c | 15 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h| 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h| 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 include/media/ti-media/dm644x_ccdc.h| 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 46 files changed, 11207 insertions(+), 11040 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/vpfe_capture.c delete mode 100644 drivers/media/video/davinci/vpif.c delete mode 100644 drivers/media/video/davinci/vpif.h delete mode 100644 drivers/media/video/davinci/vpif_capture.c delete mode 100644 drivers/media/video/davinci/vpif_capture.h delete mode 100644 drivers/media/video/davinci/vpif_display.c delete mode 100644 drivers/media/video/davinci/vpif_display.h delete mode 100644 drivers/media/video/davinci/vpss.c create mode 100644 drivers/media/video/ti-media/Kconfig create mode 100644 drivers/media/video/ti-media/Makefile create mode 100644 drivers/media/video/ti-media/ccdc_hw_device.h create mode 100644 drivers/media/video/ti-media/dm355_ccdc.c create mode 100644 drivers/media/video/ti-media/dm355_ccdc_regs.h create mode 100644 drivers/media/video/ti-media/dm644x_ccdc.c create mode 100644 drivers/media/video/ti-media/dm644x_ccdc_regs.h create mode 100644 drivers/media/video/ti-media/vpfe_capture.c create mode
[PATCH 5/9] DMx:Update board files for ti-media directory change
From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h index 85536d8..ffba662 100644 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ b/arch/arm/mach-davinci/include/mach/dm355.h @@ -13,7 +13,7 @@ #include #include -#include +#include #define ASP1_TX_EVT_EN 1 #define ASP1_RX_EVT_EN 2 diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 44e8f0f..95f1e65 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h @@ -25,7 +25,7 @@ #include #include #include -#include +#include #define DM644X_EMAC_BASE (0x01C8) #define DM644X_EMAC_CNTRL_OFFSET (0x) -- 1.6.2.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
[PATCH 6/9] Davinci VPFE Capture:Return 0 from suspend/resume
From: Vaibhav Hiremath
Now Suspend/Resume functionality is being handled by respective CCDC
code, so return true (0) from bridge suspend/resume function.
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/vpfe_capture.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 3257d26..7187eaa 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -2007,18 +2007,14 @@ static int vpfe_remove(struct platform_device *pdev)
return 0;
}
-static int
-vpfe_suspend(struct device *dev)
+static int vpfe_suspend(struct device *dev)
{
- /* add suspend code here later */
- return -1;
+ return 0;
}
-static int
-vpfe_resume(struct device *dev)
+static int vpfe_resume(struct device *dev)
{
- /* add resume code here later */
- return -1;
+ return 0;
}
static const struct dev_pm_ops vpfe_dev_pm_ops = {
--
1.6.2.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
[PATCH 2/9] TVP514x:Switch to automode for querystd
From: Vaibhav Hiremath Driver should switch to AutoSwitch mode on QUERYSTD ioctls. It has been observed that, if user configure the standard explicitely then driver preserves the old settings, but query_std must detect the standard instead of returning old settings. Signed-off-by: Vaibhav Hiremath --- drivers/media/video/tvp514x.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c index 26b4e71..4cf3593 100644 --- a/drivers/media/video/tvp514x.c +++ b/drivers/media/video/tvp514x.c @@ -523,10 +523,18 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, v4l2_std_id *std_id) enum tvp514x_std current_std; enum tvp514x_input input_sel; u8 sync_lock_status, lock_mask; + int err; if (std_id == NULL) return -EINVAL; + err = tvp514x_write_reg(sd, REG_VIDEO_STD, + VIDEO_STD_AUTO_SWITCH_BIT); + if (err < 0) + return err; + + msleep(LOCK_RETRY_DELAY); + /* get the current standard */ current_std = tvp514x_get_current_std(sd); if (current_std == STD_INVALID) -- 1.6.2.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
[PATCH 3/9] tvp514x: add YUYV format support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/tvp514x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4cf3593..b344b58 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -212,6 +212,13 @@ static const struct v4l2_fmtdesc tvp514x_fmt_list[] = {
.description = "8-bit UYVY 4:2:2 Format",
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+.index = 1,
+.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+.flags = 0,
+.description = "8-bit YUYV 4:2:2 Format",
+.pixelformat = V4L2_PIX_FMT_YUYV,
+ },
};
/**
--
1.6.2.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
[PATCH 9/9] DM644x CCDC: Add 10bit BT support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/dm644x_ccdc.c | 16 +---
drivers/media/video/ti-media/dm644x_ccdc_regs.h |8
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index b762f99..8483467 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -401,7 +401,11 @@ void ccdc_config_ycbcr(void)
* configure the FID, VD, HD pin polarity,
* fld,hd pol positive, vd negative, 8-bit data
*/
- syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE | CCDC_SYN_MODE_8BITS;
+ syn_mode |= CCDC_SYN_MODE_VD_POL_NEGATIVE;
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ syn_mode |= CCDC_SYN_MODE_10BITS;
+ else
+ syn_mode |= CCDC_SYN_MODE_8BITS;
} else {
/* y/c external sync mode */
syn_mode |= (((params->fid_pol & CCDC_FID_POL_MASK) <<
@@ -420,8 +424,13 @@ void ccdc_config_ycbcr(void)
* configure the order of y cb cr in SDRAM, and disable latch
* internal register on vsync
*/
- regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
-CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
+ if (ccdc_cfg.if_type == VPFE_BT656_10BIT)
+ regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE | CCDC_CCDCFG_BW656_10BIT,
+ CCDC_CCDCFG);
+ else
+ regw((params->pix_order << CCDC_CCDCFG_Y8POS_SHIFT) |
+ CCDC_LATCH_ON_VSYNC_DISABLE, CCDC_CCDCFG);
/*
* configure the horizontal line offset. This should be a
@@ -828,6 +837,7 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
case VPFE_BT656:
case VPFE_YCBCR_SYNC_16:
case VPFE_YCBCR_SYNC_8:
+ case VPFE_BT656_10BIT:
ccdc_cfg.ycbcr.vd_pol = params->vdpol;
ccdc_cfg.ycbcr.hd_pol = params->hdpol;
break;
diff --git a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
index 319253a..90370e4 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc_regs.h
+++ b/drivers/media/video/ti-media/dm644x_ccdc_regs.h
@@ -135,11 +135,19 @@
#define CCDC_SYN_MODE_INPMOD_SHIFT 12
#define CCDC_SYN_MODE_INPMOD_MASK 3
#define CCDC_SYN_MODE_8BITS(7 << 8)
+#define CCDC_SYN_MODE_10BITS (6 << 8)
+#define CCDC_SYN_MODE_11BITS (5 << 8)
+#define CCDC_SYN_MODE_12BITS (4 << 8)
+#define CCDC_SYN_MODE_13BITS (3 << 8)
+#define CCDC_SYN_MODE_14BITS (2 << 8)
+#define CCDC_SYN_MODE_15BITS (1 << 8)
+#define CCDC_SYN_MODE_16BITS (0 << 8)
#define CCDC_SYN_FLDMODE_MASK 1
#define CCDC_SYN_FLDMODE_SHIFT 7
#define CCDC_REC656IF_BT656_EN 3
#define CCDC_SYN_MODE_VD_POL_NEGATIVE (1 << 2)
#define CCDC_CCDCFG_Y8POS_SHIFT11
+#define CCDC_CCDCFG_BW656_10BIT(1 << 5)
#define CCDC_SDOFST_FIELD_INTERLEAVED 0x249
#define CCDC_NO_CULLING0x00ff
#endif
--
1.6.2.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
[PATCH 8/9] VPFE Capture: Add call back function for interrupt clear to vpfe_cfg
From: Vaibhav Hiremath
For the devices like AM3517, it is expected that driver clears the
interrupt in ISR. Since this is device spcific, callback function
added to the platform_data.
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/vpfe_capture.c | 24
include/media/ti-media/vpfe_capture.h |2 ++
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ti-media/vpfe_capture.c
b/drivers/media/video/ti-media/vpfe_capture.c
index 7187eaa..95538b2 100644
--- a/drivers/media/video/ti-media/vpfe_capture.c
+++ b/drivers/media/video/ti-media/vpfe_capture.c
@@ -475,6 +475,11 @@ static int vpfe_initialize_device(struct vpfe_device
*vpfe_dev)
ret = ccdc_dev->hw_ops.open(vpfe_dev->pdev);
if (!ret)
vpfe_dev->initialized = 1;
+
+ /* Clear all VPFE/CCDC interrupts */
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(-1);
+
unlock:
mutex_unlock(&ccdc_lock);
return ret;
@@ -562,7 +567,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
/* if streaming not started, don't do anything */
if (!vpfe_dev->started)
- return IRQ_HANDLED;
+ goto clear_intr;
/* only for 6446 this will be applicable */
if (NULL != ccdc_dev->hw_ops.reset)
@@ -574,7 +579,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
"frame format is progressive...\n");
if (vpfe_dev->cur_frm != vpfe_dev->next_frm)
vpfe_process_buffer_complete(vpfe_dev);
- return IRQ_HANDLED;
+ goto clear_intr;
}
/* interlaced or TB capture check which field we are in hardware */
@@ -604,7 +609,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
addr += vpfe_dev->field_off;
ccdc_dev->hw_ops.setfbaddr(addr);
}
- return IRQ_HANDLED;
+ goto clear_intr;
}
/*
* if one field is just being captured configure
@@ -624,6 +629,10 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
*/
vpfe_dev->field_id = fid;
}
+clear_intr:
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
+
return IRQ_HANDLED;
}
@@ -635,8 +644,11 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nInside vdint1_isr...\n");
/* if streaming not started, don't do anything */
- if (!vpfe_dev->started)
+ if (!vpfe_dev->started) {
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
return IRQ_HANDLED;
+ }
spin_lock(&vpfe_dev->dma_queue_lock);
if ((vpfe_dev->fmt.fmt.pix.field == V4L2_FIELD_NONE) &&
@@ -644,6 +656,10 @@ static irqreturn_t vdint1_isr(int irq, void *dev_id)
vpfe_dev->cur_frm == vpfe_dev->next_frm)
vpfe_schedule_next_buffer(vpfe_dev);
spin_unlock(&vpfe_dev->dma_queue_lock);
+
+ if (vpfe_dev->cfg->clr_intr)
+ vpfe_dev->cfg->clr_intr(irq);
+
return IRQ_HANDLED;
}
diff --git a/include/media/ti-media/vpfe_capture.h
b/include/media/ti-media/vpfe_capture.h
index 5287368..f0a7b7a 100644
--- a/include/media/ti-media/vpfe_capture.h
+++ b/include/media/ti-media/vpfe_capture.h
@@ -94,6 +94,8 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* Function for Clearing the interrupt */
+ void (*clr_intr)(int vdint);
};
struct vpfe_device {
--
1.6.2.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
[PATCH 1/9] Makfile:Removed duplicate entry of davinci
From: Vaibhav Hiremath Signed-off-by: Vaibhav Hiremath --- drivers/media/video/Makefile |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2af68ee..bebbee6 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -158,8 +158,6 @@ obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ - obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ -- 1.6.2.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
[PATCH 7/9] DM644x CCDC : Add Suspend/Resume Support
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/ti-media/dm644x_ccdc.c | 114 +++
drivers/media/video/ti-media/dm644x_ccdc_regs.h |2 +-
2 files changed, 115 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ti-media/dm644x_ccdc.c
b/drivers/media/video/ti-media/dm644x_ccdc.c
index 8b5d4c5..b762f99 100644
--- a/drivers/media/video/ti-media/dm644x_ccdc.c
+++ b/drivers/media/video/ti-media/dm644x_ccdc.c
@@ -99,6 +99,9 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+/* CCDC Save/Restore context */
+static u32 ccdc_ctx[CCDC_REG_END / sizeof(u32)];
+
/* register access routines */
static inline u32 regr(u32 offset)
{
@@ -835,6 +838,87 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
return 0;
}
+static void ccdc_save_context(void)
+{
+ ccdc_ctx[CCDC_PCR >> 2] = regr(CCDC_PCR);
+ ccdc_ctx[CCDC_SYN_MODE >> 2] = regr(CCDC_SYN_MODE);
+ ccdc_ctx[CCDC_HD_VD_WID >> 2] = regr(CCDC_HD_VD_WID);
+ ccdc_ctx[CCDC_PIX_LINES >> 2] = regr(CCDC_PIX_LINES);
+ ccdc_ctx[CCDC_HORZ_INFO >> 2] = regr(CCDC_HORZ_INFO);
+ ccdc_ctx[CCDC_VERT_START >> 2] = regr(CCDC_VERT_START);
+ ccdc_ctx[CCDC_VERT_LINES >> 2] = regr(CCDC_VERT_LINES);
+ ccdc_ctx[CCDC_CULLING >> 2] = regr(CCDC_CULLING);
+ ccdc_ctx[CCDC_HSIZE_OFF >> 2] = regr(CCDC_HSIZE_OFF);
+ ccdc_ctx[CCDC_SDOFST >> 2] = regr(CCDC_SDOFST);
+ ccdc_ctx[CCDC_SDR_ADDR >> 2] = regr(CCDC_SDR_ADDR);
+ ccdc_ctx[CCDC_CLAMP >> 2] = regr(CCDC_CLAMP);
+ ccdc_ctx[CCDC_DCSUB >> 2] = regr(CCDC_DCSUB);
+ ccdc_ctx[CCDC_COLPTN >> 2] = regr(CCDC_COLPTN);
+ ccdc_ctx[CCDC_BLKCMP >> 2] = regr(CCDC_BLKCMP);
+ ccdc_ctx[CCDC_FPC >> 2] = regr(CCDC_FPC);
+ ccdc_ctx[CCDC_FPC_ADDR >> 2] = regr(CCDC_FPC_ADDR);
+ ccdc_ctx[CCDC_VDINT >> 2] = regr(CCDC_VDINT);
+ ccdc_ctx[CCDC_ALAW >> 2] = regr(CCDC_ALAW);
+ ccdc_ctx[CCDC_REC656IF >> 2] = regr(CCDC_REC656IF);
+ ccdc_ctx[CCDC_CCDCFG >> 2] = regr(CCDC_CCDCFG);
+ ccdc_ctx[CCDC_FMTCFG >> 2] = regr(CCDC_FMTCFG);
+ ccdc_ctx[CCDC_FMT_HORZ >> 2] = regr(CCDC_FMT_HORZ);
+ ccdc_ctx[CCDC_FMT_VERT >> 2] = regr(CCDC_FMT_VERT);
+ ccdc_ctx[CCDC_FMT_ADDR0 >> 2] = regr(CCDC_FMT_ADDR0);
+ ccdc_ctx[CCDC_FMT_ADDR1 >> 2] = regr(CCDC_FMT_ADDR1);
+ ccdc_ctx[CCDC_FMT_ADDR2 >> 2] = regr(CCDC_FMT_ADDR2);
+ ccdc_ctx[CCDC_FMT_ADDR3 >> 2] = regr(CCDC_FMT_ADDR3);
+ ccdc_ctx[CCDC_FMT_ADDR4 >> 2] = regr(CCDC_FMT_ADDR4);
+ ccdc_ctx[CCDC_FMT_ADDR5 >> 2] = regr(CCDC_FMT_ADDR5);
+ ccdc_ctx[CCDC_FMT_ADDR6 >> 2] = regr(CCDC_FMT_ADDR6);
+ ccdc_ctx[CCDC_FMT_ADDR7 >> 2] = regr(CCDC_FMT_ADDR7);
+ ccdc_ctx[CCDC_PRGEVEN_0 >> 2] = regr(CCDC_PRGEVEN_0);
+ ccdc_ctx[CCDC_PRGEVEN_1 >> 2] = regr(CCDC_PRGEVEN_1);
+ ccdc_ctx[CCDC_PRGODD_0 >> 2] = regr(CCDC_PRGODD_0);
+ ccdc_ctx[CCDC_PRGODD_1 >> 2] = regr(CCDC_PRGODD_1);
+ ccdc_ctx[CCDC_VP_OUT >> 2] = regr(CCDC_VP_OUT);
+}
+
+static void ccdc_restore_context(void)
+{
+ regw(ccdc_ctx[CCDC_SYN_MODE >> 2], CCDC_SYN_MODE);
+ regw(ccdc_ctx[CCDC_HD_VD_WID >> 2], CCDC_HD_VD_WID);
+ regw(ccdc_ctx[CCDC_PIX_LINES >> 2], CCDC_PIX_LINES);
+ regw(ccdc_ctx[CCDC_HORZ_INFO >> 2], CCDC_HORZ_INFO);
+ regw(ccdc_ctx[CCDC_VERT_START >> 2], CCDC_VERT_START);
+ regw(ccdc_ctx[CCDC_VERT_LINES >> 2], CCDC_VERT_LINES);
+ regw(ccdc_ctx[CCDC_CULLING >> 2], CCDC_CULLING);
+ regw(ccdc_ctx[CCDC_HSIZE_OFF >> 2], CCDC_HSIZE_OFF);
+ regw(ccdc_ctx[CCDC_SDOFST >> 2], CCDC_SDOFST);
+ regw(ccdc_ctx[CCDC_SDR_ADDR >> 2], CCDC_SDR_ADDR);
+ regw(ccdc_ctx[CCDC_CLAMP >> 2], CCDC_CLAMP);
+ regw(ccdc_ctx[CCDC_DCSUB >> 2], CCDC_DCSUB);
+ regw(ccdc_ctx[CCDC_COLPTN >> 2], CCDC_COLPTN);
+ regw(ccdc_ctx[CCDC_BLKCMP >> 2], CCDC_BLKCMP);
+ regw(ccdc_ctx[CCDC_FPC >> 2], CCDC_FPC);
+ regw(ccdc_ctx[CCDC_FPC_ADDR >> 2], CCDC_FPC_ADDR);
+ regw(ccdc_ctx[CCDC_VDINT >> 2], CCDC_VDINT);
+ regw(ccdc_ctx[CCDC_ALAW >> 2], CCDC_ALAW);
+ regw(ccdc_ctx[CCDC_REC656IF >> 2], CCDC_REC656IF);
+ regw(ccdc_ctx[CCDC_CCDCFG >> 2], CCDC_CCDCFG);
+ regw(ccdc_ctx[CCDC_FMTCFG >> 2], CCDC_FMTCFG);
+ regw(ccdc_ctx[CCDC_FMT_HORZ >> 2], CCDC_FMT_HORZ);
+ regw(ccdc_ctx[CCDC_FMT_VERT >> 2], CCDC_FMT_VERT);
+ regw(ccdc_ctx[CCDC_FMT_ADDR0 >> 2], CCDC_FMT_ADDR0);
+ regw(ccdc_ctx[CCDC_FMT_ADDR1 >> 2], CCDC_FMT_ADDR1);
+ regw(ccdc_ctx[CCDC_FMT_ADDR2 >> 2], CCDC_FMT_ADDR2);
+ regw(ccdc_ctx[CCDC_FMT_ADDR3 >> 2], CCDC_FMT_ADDR3);
+ regw(ccdc_ctx[CCDC_FMT_ADDR4 >> 2], CCDC_FMT_ADDR4);
+ regw(ccdc_ctx[CCDC_FMT_ADDR5 >> 2], CCDC_FMT_ADDR5);
+ regw(ccdc_ctx[CCDC_FMT_ADDR6 >> 2], CCDC_FMT_ADDR6);
+ regw(ccdc_ctx[CCDC_FMT_ADDR7 >> 2], CCDC_FMT_ADDR7);
+ regw(ccdc_ctx
Re: Technisat SkyStar HD S2 USB
Hi Martin, On Sat, 2 Jan 2010, Martin Berndaner wrote: Dear all, i want to use the Technisat SkyStar HD S2 USB for building a PVR. Does anyone know, if this Box is supported in the near future? (USB VID 0x14f7, PID 0x0002) Actually i couldn`t find a valid driver. That's normal, because there isn't. But there will be at some point in time. I can't give you an exact date right now, but there is a chance that it might happen during the first quarter of 2010. best regards, Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: Add V4L2 display driver support
From: Vaibhav Hiremath This series of patch-set adds support for V4L2 display driver ontop of DSS2 framework. Please note that this patch is dependent on patch which add "ti-media" directory (submitted earlier to this patch series) Vaibhav Hiremath (2): OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 OMAP2/3: Add V4L2 DSS driver support in device.c arch/arm/plat-omap/devices.c| 29 + drivers/media/video/ti-media/Kconfig| 10 + drivers/media/video/ti-media/Makefile |4 + drivers/media/video/ti-media/omap_vout.c| 2654 +++ drivers/media/video/ti-media/omap_voutdef.h | 148 ++ drivers/media/video/ti-media/omap_voutlib.c | 258 +++ drivers/media/video/ti-media/omap_voutlib.h | 34 + 7 files changed, 3137 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ti-media/omap_vout.c create mode 100644 drivers/media/video/ti-media/omap_voutdef.h create mode 100644 drivers/media/video/ti-media/omap_voutlib.c create mode 100644 drivers/media/video/ti-media/omap_voutlib.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
[PATCH 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
---
arch/arm/plat-omap/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 30b5db7..64f2a3a 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -357,6 +357,34 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
+/*---*/
+
+#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
+ defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
+#if defined (CONFIG_FB_OMAP2) || defined (CONFIG_FB_OMAP2_MODULE)
+static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
+};
+#else
+static struct resource omap_vout_resource[2] = {
+};
+#endif
+
+static struct platform_device omap_vout_device = {
+ .name = "omap_vout",
+ .num_resources = ARRAY_SIZE(omap_vout_resource),
+ .resource = &omap_vout_resource[0],
+ .id = -1,
+};
+static void omap_init_vout(void)
+{
+ (void) platform_device_register(&omap_vout_device);
+}
+#else
+static inline void omap_init_vout(void) {}
+#endif
+
+/*---*/
+
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
@@ -387,6 +415,7 @@ static int __init omap_init_devices(void)
omap_init_rng();
omap_init_uwire();
omap_init_wdt();
+ omap_init_vout();
return 0;
}
arch_initcall(omap_init_devices);
--
1.6.2.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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Sun, 3 Jan 2010, Sean wrote: > Alan, > > I applied the patches and ran capture-example twice. On the second run > of capture-example a circular pointer popped up. I did not need to > remove the camera. Attached are the serial console capture as well as > the dmesg log in debug4.tar.gz. Did you want me to try to reproduce the > poison message? No. Among the things that patch did was to fix up the errors that caused the invalid pointers. Hence there should not have been any "poisoned hash" messages -- and indeed there weren't. The interesting part of the log is the error messages: ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 1 c6774040 c6542040 c6774040 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 1 c6774040 c6542040 c6774040 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 1 c6774040 c6542040 c6774040 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 ohci_hcd :00:0b.0: Circular pointer #2b: 32 c6774800 c6542800 c6774800 There are two different hash chains here (32 and 1), but in each case see the message is #2b, never #2a. This means the problem occurs between the places where the #2a and #2b messages were inserted, i.e., in td_fill(). The hash chain contained a single TD and was fine to begin with; then another TD was added at the start of the chain and the pointer in the earlier TD (now at the second position in the chain) got messed up. For example, the error message in the first line above implies that originally the 32nd hash chain contained only the TD at c6542800 with its td_hash member set to NULL. But then c6774800 was added to the start of the chain, after which c6542800's td_hash pointed to c6774800. Try inserting a line saying: td_check(ohci, hash, "#2c"); two lines above the #2b line, i.e., just after the wmb(). That'll help narrow down the search for the bug. And by the way, you don't need to post your entire dmesg log. Just the portion containing the new debugging messages will be enough. Alan Stern -- 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: DTV2000 H Plus issues
On 01/03/2010 09:21 AM, Raena Lea-Shannon wrote: > That seems odd. This patch on the LinuxTv site > http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html > seems to be using the cx88 drivers? Unfortunately, this patch is for the older DTV 2000H (not Plus) card, which uses a Philips FMD1216 tuner. The main change on the "Plus" card is the replacement of the tuner with the XC4000, and that is why it is not supported yet. However, an XC4000 driver is already under development, and - compiling V4L from source - you could get the card working in the near future. In fact, code that implements support for this card already exists, but it is only for development/testing at the moment. -- 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] dvb-apps ported for ISDB-T
On Fri, Jan 1, 2010 at 2:23 AM, Mauro Carvalho Chehab wrote: > Patrick Boettcher wrote: >> Hi Mauro, >> >> On Fri, 25 Dec 2009, Mauro Carvalho Chehab wrote: >> >>> Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: I wrote several patches those days in order to allow dvb-apps to properly parse ISDB-T channel.conf. On ISDB-T, there are several new parameters, so the parsing is more complex than all the other currently supported video standards. I've added the changes at: http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ I've merged there Patrick's dvb-apps-isdbt tree. While there, I fixed a few bugs I noticed on the parser and converted it to work with the DVB API v5 headers that are bundled together with dvb-apps. This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones there can now be removed. TODO: = The new ISDB-T parameters are parsed, but I haven't add yet a code to make them to be used; There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the segment parameters. Currently, the parser will fail if those parameters are found. gnutv is still reporting ISDB-T as "DVB-T". >>> >>> I've just fixed the issues on the TODO list. The DVB v5 code is now >>> working fine >>> for ISDB-T. >>> >>> Pending stuff (patches are welcome): >>> - Implement v5 calls for other video standards; >>> - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code >>> for calling >>> DVBv5 is now at /lib/libdvbapi/v5api.c); >>> - Test/use the functions to retrieve values via DVBv5 API. The >>> function is >>> already there, but I haven't tested. >>> >>> With the DVBv5 API implementation, zap is now working properly with >>> ISDB-T. >>> gnutv also works (although some outputs - like decoder - may need some >>> changes, in >>> order to work with mpeg4/AAC video/audio codecs). >> >> Very good job! >> >> Have you had a look here on this one >> >> http://www.mail-archive.com/v...@linuxtv.org/msg11125.html >> >> ? >> >> I had this on my list because I wanted to spent some time on DVB-S2 >> myself and it seemed to be a good step to merge it (back) into dvb-apps. >> Though I haven't yet looked at it in detail. >> >> I will check your changes soon, but after the holidays. >> >> So, now you should have some quiet time for yourself! ;-) > > Ok, I've added a version 2 of the isdbt-aware dvb-apps scan tools. > > Basically, this version: > - checks if v5 API is available on a driver. If not, it falls back to > v3 API; > - v5api.c is now fully internal to libdvbfe. For library clients, it > is fully transparent if it is using v5 or v3 calls; > - scan now uses libdvbfe, instead of directly implementing the > ioctls for v3 and v5. The code were simplified by the removal of lots of if's > for v5 API; > - scan now supports a few parameters present on DVB-S2, but there > are still a few missing bits to fully support DVB-S2; > - as my previous tree, dvb-apps has a copy of the dvb headers, since > the headers are stable enough to work with older drivers and since the API > version check is done by an ioctl call; > - it addresses the pertinent issues that Manu pointed. It still remains the same, however. I had a quick look at it again: - dvb-apps/libs stopped using a separate copy of the kernel headers; ie kernel headers are expected to be at the default system locations, ie the kernel headers package. Because you added it in again, a test app szap2 had to be disabled for compilation. Changesets: 1332, 1334, 1348, 1357 - the library is falling on an expected operation for V5. This can fail if the API is V3 or something else. It should check the header version and if it is known to be greater than V3, then only it should issue the new V5 ioctl to test for version. This frees from an unnecessary test in the case of the V3 API. Changeset 1336 - Please do not apply partial features. Either apply it, or don't. Changeset 1341 - ATSC Cable is not DVB-C, even though it has some similiarities. Let's not get things mixed up. Changeset 1344 - Let the application send the number of properties, not the library to do memory allocation and deallocation. I mentioned about this one in my previous reply to your post. fill_sys_v5_params() --> count_props() Changeset: 1350, 1359, 1360 sizeof applies to a data structure, not the pointer, Changeset 1360 - maintain Backward compatibility with V3. Changeset 1351 > Yet, this version is not properly tested, but, as I intend to be on vacations > next week, I wanted to post what I have, even without all tests, to avoid the > risk of someone to be working on DVB-S2 or other improvements to do a similar > work. - Memory management needs string.h v5api.c:512: warning: implicit declaration of function ‘memset’ v5api.c:512: warning: incompatible impl
libv4l2: error mmapping buffer 0: Permission denied
Hello, I'm trying to get a labtec 2200 usb webcam working on my custom ARM platform. Since that webcam produces only images in pjpeg, I'm using libv4l2. I wrote a simple capture application where I want to read a single image in rgb24. When the application invokes v4l2_read I get the above error. The error comes from mmap which is invoked in libv4l2, but I've no idea whats wrong there. Can someone give me a hint how to fix this? Thanks Niko -- 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
Call for Testers - dib0700 IR improvements
Hello all, I have done some refactoring of the dib0700 IR code for firmware 1.20, which should address concerns about the high load average when devices are connected. It might also address people's reports of mt2060 errors on the Nova-T 500 after several hours of operation (which would occur unless they used the disable_ir_polling modprobe option). I am looking for feedback from users who have dib0700 based devices and have reported problems with IR support in the past. The tree can be found here: http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir More info can be found here: http://www.kernellabs.com/blog/?p=1292 Cheers, 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: Call for Testers - dib0700 IR improvements
On Mon, 4 Jan 2010, Devin Heitmueller wrote: Hello all, I have done some refactoring of the dib0700 IR code for firmware 1.20, which should address concerns about the high load average when devices are connected. It might also address people's reports of mt2060 errors on the Nova-T 500 after several hours of operation (which would occur unless they used the disable_ir_polling modprobe option). I am looking for feedback from users who have dib0700 based devices and have reported problems with IR support in the past. The tree can be found here: http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir Very good job. Reviewed-by: Patrick Boettcher also Acked-by: Patrick Boettcher Pick one. Thanks, -- Patrick Boettcher - 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: Technisat SkyStar HD S2 USB
Hi Patrick, thank you for the information. If i can support, let me know it. Regards, Martin. Patrick Boettcher schrieb: > Hi Martin, > > On Sat, 2 Jan 2010, Martin Berndaner wrote: > >> Dear all, >> >> i want to use the Technisat SkyStar HD S2 USB for building a PVR. >> Does anyone know, if this Box is supported in the near future? >> (USB VID 0x14f7, PID 0x0002) >> Actually i couldn`t find a valid driver. > > That's normal, because there isn't. But there will be at some point in > time. I can't give you an exact date right now, but there is a chance > that it might happen during the first quarter of 2010. > > best regards, > Patrick. > > -- 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: OK
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 Jan 4 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e 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.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS 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.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK 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 linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK 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: OK 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/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
Re: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote: Try inserting a line saying: td_check(ohci, hash, "#2c"); two lines above the #2b line, i.e., just after the wmb(). That'll help narrow down the search for the bug. Alan, I put the extra line in and ran capture-example twice. This is what I got: ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 1 c6782040 c66a4040 c6782040 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 1 c6782040 c66a4040 c6782040 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 1 c6782040 c66a4040 c6782040 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 1 c6782040 c66a4040 c6782040 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800 Sean -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Mon, 4 Jan 2010, Sean wrote:
> Alan Stern wrote:
> > Try inserting a line saying:
> >
> > td_check(ohci, hash, "#2c");
> >
> > two lines above the #2b line, i.e., just after the wmb(). That'll help
> > narrow down the search for the bug.
> Alan,
>
> I put the extra line in and ran capture-example twice. This is what I got:
>
> ohci_hcd :00:0b.0: Circular pointer #2c: 32 c6782800 c66a4800 c6782800
> ohci_hcd :00:0b.0: Circular pointer #2c: 1 c6782040 c66a4040 c6782040
...
All right. Let's try this patch in place of all the others, then.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-q.c
+++ usb-2.6/drivers/usb/host/ohci-q.c
@@ -505,6 +505,7 @@ td_fill (struct ohci_hcd *ohci, u32 info
struct urb_priv *urb_priv = urb->hcpriv;
int is_iso = info & TD_ISO;
int hash;
+ volatile struct td * volatile td1, * volatile td2;
// ASSERT (index < urb_priv->length);
@@ -558,11 +559,30 @@ td_fill (struct ohci_hcd *ohci, u32 info
/* hash it for later reverse mapping */
hash = TD_HASH_FUNC (td->td_dma);
+
+ td1 = ohci->td_hash[hash];
+ td2 = NULL;
+ if (td1) {
+ td2 = td1->td_hash;
+ if (td2 == td1 || td2 == td) {
+ ohci_err(ohci, "Circular hash: %d %p %p %p\n",
+ hash, td1, td2, td);
+ td2 = td1->td_hash = NULL;
+ }
+ }
+
td->td_hash = ohci->td_hash [hash];
ohci->td_hash [hash] = td;
/* HC might read the TD (or cachelines) right away ... */
wmb ();
+
+ if (td1 && td1->td_hash != td2) {
+ ohci_err(ohci, "Hash value changed: %d %p %p %p\n",
+ hash, td1, td2, td);
+ td1->td_hash = (struct td *) td2;
+ }
+
td->ed->hwTailP = td->hwNextTD;
}
--
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] rj54n1cb0c: remove compiler warning
Hi Márton On Sun, 3 Jan 2010, Németh Márton wrote: > From: Márton Németh > > Remove the following compiler warning: 'dummy' is used uninitialized in this > function. > Although the result in the dummy variable is not used the program flow in > soc_camera_limit_side() depends on the value in dummy. The program flow is > better > to be deterministic. > > Signed-off-by: Márton Németh The patch is good, the only slight problem - you have non-ASCII characters in your name and you didn't use UTF-8 to send this mail, which, I think, is the accepted encoding in the Linux kernel. I converted your patch to utf8 and attached to this mail. Please verify that the result is correct. > --- > diff -r 62ee2b0f6556 linux/drivers/media/video/rj54n1cb0c.c > --- a/linux/drivers/media/video/rj54n1cb0c.c Wed Dec 30 18:19:11 2009 +0100 > +++ b/linux/drivers/media/video/rj54n1cb0c.c Sun Jan 03 21:30:20 2010 +0100 > @@ -563,7 +563,7 @@ > struct i2c_client *client = sd->priv; > struct rj54n1 *rj54n1 = to_rj54n1(client); > struct v4l2_rect *rect = &a->c; > - unsigned int dummy, output_w, output_h, > + unsigned int dummy = 0, output_w, output_h, > input_w = rect->width, input_h = rect->height; > int ret; > Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/From nm...@freemail.hu Sun Jan 3 21:38:51 2010 Date: Sun, 03 Jan 2010 21:34:59 +0100 From: Németh Márton To: Guennadi Liakhovetski Cc: Hans Verkuil , V4L Mailing List Subject: [PATCH] rj54n1cb0c: remove compiler warning From: Márton Németh Remove the following compiler warning: 'dummy' is used uninitialized in this function. Although the result in the dummy variable is not used the program flow in soc_camera_limit_side() depends on the value in dummy. The program flow is better to be deterministic. Signed-off-by: Márton Németh --- diff -r 62ee2b0f6556 linux/drivers/media/video/rj54n1cb0c.c --- a/linux/drivers/media/video/rj54n1cb0c.c Wed Dec 30 18:19:11 2009 +0100 +++ b/linux/drivers/media/video/rj54n1cb0c.c Sun Jan 03 21:30:20 2010 +0100 @@ -563,7 +563,7 @@ struct i2c_client *client = sd->priv; struct rj54n1 *rj54n1 = to_rj54n1(client); struct v4l2_rect *rect = &a->c; - unsigned int dummy, output_w, output_h, + unsigned int dummy = 0, output_w, output_h, input_w = rect->width, input_h = rect->height; int ret;
Re: [PATCH] rj54n1cb0c: remove compiler warning
Guennadi Liakhovetski wrote: > Hi Márton > > On Sun, 3 Jan 2010, Németh Márton wrote: > >> From: Márton Németh >> >> Remove the following compiler warning: 'dummy' is used uninitialized in this >> function. >> Although the result in the dummy variable is not used the program flow in >> soc_camera_limit_side() depends on the value in dummy. The program flow is >> better >> to be deterministic. >> >> Signed-off-by: Márton Németh > > The patch is good, the only slight problem - you have non-ASCII characters > in your name and you didn't use UTF-8 to send this mail, which, I think, > is the accepted encoding in the Linux kernel. I converted your patch to > utf8 and attached to this mail. Please verify that the result is correct. Your conversion is OK. Sorry about this issue. Regards, Márton Németh -- 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
Request for confirmation
Sorry to bother you: we are cleaning up our database and it appears that you have previously signed up to eBuppies.com mailinglists and not confirmed your subscription.We would like to give you the opportunity to re-confirm your subscription. The instructions on how to confirm are below. Almost welcome to our newsletter(s) ... Someone, hopefully you, has subscribed your email address to the following newsletters: If this is correct, please click the following link to confirm your subscription. Without this confirmation, you will not receive any newsletters. http://ebuppies.com/emailserv/?p=confirm&uid=a147fb9820af0ed588b116f6749759f7 If this is not correct, you do not need to do anything, simply delete this message. Thank you -- 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
Welcome to our Newsletter
Welcome to our Newsletter Please keep this email for later reference. Your email address has been added to the following newsletter(s): * None of them To update your details and preferences please go to http://ebuppies.com/emailserv/?p=preferences&uid=a147fb9820af0ed588b116f6749759f7. If you do not want to receive any more messages, please go to http://ebuppies.com/emailserv/?p=unsubscribe&uid=a147fb9820af0ed588b116f6749759f7. Thank you -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote:
...
All right. Let's try this patch in place of all the others, then.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-q.c
+++ usb-2.6/drivers/usb/host/ohci-q.c
@@ -505,6 +505,7 @@ td_fill (struct ohci_hcd *ohci, u32 info
struct urb_priv *urb_priv = urb->hcpriv;
int is_iso = info & TD_ISO;
int hash;
+ volatile struct td * volatile td1, * volatile td2;
// ASSERT (index < urb_priv->length);
@@ -558,11 +559,30 @@ td_fill (struct ohci_hcd *ohci, u32 info
/* hash it for later reverse mapping */
hash = TD_HASH_FUNC (td->td_dma);
+
+ td1 = ohci->td_hash[hash];
+ td2 = NULL;
+ if (td1) {
+ td2 = td1->td_hash;
+ if (td2 == td1 || td2 == td) {
+ ohci_err(ohci, "Circular hash: %d %p %p %p\n",
+ hash, td1, td2, td);
+ td2 = td1->td_hash = NULL;
+ }
+ }
+
td->td_hash = ohci->td_hash [hash];
ohci->td_hash [hash] = td;
/* HC might read the TD (or cachelines) right away ... */
wmb ();
+
+ if (td1 && td1->td_hash != td2) {
+ ohci_err(ohci, "Hash value changed: %d %p %p %p\n",
+ hash, td1, td2, td);
+ td1->td_hash = (struct td *) td2;
+ }
+
td->ed->hwTailP = td->hwNextTD;
}
Alan,
This last patch seems to do the job. Thanks so much for your help! Where
do I donate/send beer?
Sean
--
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: DVBWorld DVB-S2 2005 PCI-Express Card
I think that`s not the same problem, maybe similar as you wrote. All 4 cards are same type. But only last one (if i write to shell #modprobe cx23885) works and show in /dev/dvb . Maybe it`s driver problem (doesn`t like more cards?). Jakub. Leszek Koltunski píše v Po 04. 01. 2010 v 19:37 +0800: > I have a very similar problem with DVBWorld 2006 DVB-S2 card. > The v4l-dvb ( freshly pulled ) compiles and loads, firmware is loaded, > but when I actually try to use it ( dvbstream commands ) the following > appears in /var/log/messages: > > Jan 4 18:30:24 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:24 november kernel: ds3000_readreg: reg=0xd1(error=-1) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_readreg: reg=0xd1(error=-1) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err > == -1, reg == 0xf9, value == 0x04) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_readreg: reg=0xf8(error=-1) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err > == -1, reg == 0x03, value == 0x12) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_tuner_readreg: reg=0x3d(error=-1) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_writereg: writereg error(err > == -1, reg == 0x03, value == 0x12) > Jan 4 18:30:25 november kernel: i2c_sendbytes: i2c error NAK or timeout occur > Jan 4 18:30:25 november kernel: ds3000_tuner_readreg: reg=0x21(error=-1) > > ... and many more of this. > > Actually I have to say I already tried DVBWorld 2006, NetUP dual > DVB-S2 and TwinHan VP-1041 ( like the Technisat card ) but no success > at all. DVBWorld is giving me errors like above, NetUP's driver loads > but doesn't want to tune to anything, Twinhan can tune to one > transponder and scan the channels but for reasons far beyond me fails > to tune to anything else. > > DVB-T ( Leadtek WinFast ) is working for me perfectly, but DVB-S is an > exercise in frustration... signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: DTV2000 H Plus issues
istva...@mailbox.hu wrote: On 01/03/2010 09:21 AM, Raena Lea-Shannon wrote: That seems odd. This patch on the LinuxTv site http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html seems to be using the cx88 drivers? Unfortunately, this patch is for the older DTV 2000H (not Plus) card, which uses a Philips FMD1216 tuner. The main change on the "Plus" card is the replacement of the tuner with the XC4000, and that is why it is not supported yet. However, an XC4000 driver is already under development, and - compiling V4L from source - you could get the card working in the near future. In fact, code that implements support for this card already exists, but it is only for development/testing at the moment. -- 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 Thanks. Will try again later. -- 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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
> > Mauro,
> >
> > I've split the revert2.diff that I sent you previously to fix the tuning
> > regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
> > that will hopefully allow you to review more easily.
> >
> > The first two patches revert their respective changesets and nothing else,
> > fixing the issue for me.
> > 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
> > 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
> >
> > The third patch does what I believe is the obvious equivalent fix to
> > e6a8672631a0 but without the cleanup that breaks tuning on my card.
> >
> > Please review and merge
> >
> > Signed-off-by: Robert Lowery
>
> Mauro,
>
> I'm yet to receive a response from you on this clear regression introduced
> in the 2.6.31 kernel. You attention would be appreciated
>
> Thanks
>
> -Rob
Robert,
The changes in question (mostly authored by me) are based on
documentation on what offsets are to be used with the firmware for
various DVB bandwidths and demodulators. The change was tested by Terry
on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and
some other cards I can't remember, using a DVB-T pattern generator for 7
and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
(Devin,
Maybe you can double check on the offsets in tuner-xc2028.c with any
documentation you have available to you?)
I haven't been following this thread really at all as the board in the
subject line was unfamiliar to me, so sorry for any late response or
dumb questions by me.
May I ask:
1. what are the exact problem frequencies?
2. what is the data source from which you are getting the frequency
information?
3. what does tuner-xc2028 debug logging show as the firmware loaded when
tune to one of the the problem frequencies?
BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
cxusb_dvico_xc3028_tuner_attach(), this declaration
static struct xc2028_ctrl ctl = {
.fname = XC2028_DEFAULT_FIRMWARE,
.max_len = 64,
.demod = XC3028_FE_ZARLINK456,
};
really should have ".type = XC2028_AUTO" or ".type = XC2028_D2633", but
since XC2028_AUTO has a value of 0, it probably doesn't matter.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 14564] capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=14564 Jean-Francois Moine changed: What|Removed |Added CC||moin...@free.fr --- Comment #22 from Jean-Francois Moine 2010-01-03 07:02:45 --- Hello Sean, Sorry to be a bit late. Looking at the dmesg, I found that the gspca version was 2.7.0. May you upgrade your linux media stuff from LinuxTv.org and check if this problem still occurs? Jef Jef, I upgraded to the latest v4l-dvb from http://linuxtv.org/hg/v4l-dvb, made the kernel modules, made the v4l libraries, and recompiled capture-example.c. Gspca now shows 2.8.0. The error still persists. Alan Stern's latest patch to ohci-q.c traps the error. I think it is an issue with the cpu or usb controller on the Vortex86SX SoC. Sean -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Mon, 4 Jan 2010, Sean wrote: > Alan, > This last patch seems to do the job. Thanks so much for your help! Where > do I donate/send beer? Um, when you say it does the job, what do you mean? The job it was _intended_ to do was to prove that your problems are caused by hardware errors rather than software bugs. If the patch causes the problems to stop, without printing any error messages in the log, then it does indeed prove this. After all, the only places the patch changes any persistent values are after it prints an error message. (Admittedly, I didn't expect the problem to stop; I expected to get a bunch of messages from the second ohci_err(). Just out of curiosity, does it make any difference if you remove all those "volatile"s in the declaration line for td1 and td2?) I noticed that your CPU is a Cyrix. Perhaps it is the culprit. Have you tried running the program on a different computer? Alan Stern -- 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: [Bug 14564] capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Mon, 4 Jan 2010, Sean wrote: > Jef, > > I upgraded to the latest v4l-dvb from http://linuxtv.org/hg/v4l-dvb, > made the kernel modules, made the v4l libraries, and recompiled > capture-example.c. Gspca now shows 2.8.0. The error still persists. Alan > Stern's latest patch to ohci-q.c traps the error. I think it is an issue > with the cpu or usb controller on the Vortex86SX SoC. The CPU is more likely than the USB controller. The erroneous pointer values we see are virtual addresses, whereas the USB controller would probably write a physical (or DMA) address if it was malfunctioning. Or it could be some bizarre timing problem with the memory bus, or something else equally obscure. You didn't mention before that this was a SoC rather than an ordinary PC. Alan Stern -- 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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Hey Andy, On Mon, Jan 4, 2010 at 9:27 PM, Andy Walls wrote: > The changes in question (mostly authored by me) are based on > documentation on what offsets are to be used with the firmware for > various DVB bandwidths and demodulators. The change was tested by Terry > on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and > some other cards I can't remember, using a DVB-T pattern generator for 7 > and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. > > (Devin, > Maybe you can double check on the offsets in tuner-xc2028.c with any > documentation you have available to you?) At this point the extent to which I've looked in to the issue was validating that, for a given frequency, the change resulted in a crappy SNR with lots of BER/UNC errors, and after reverting the change the signal looked really good with zero BER/UNC. I haven't dug into *why* it is an issue, but I examined the traces and looked at the testing methodology and can confirm that there was definitely a regression and Robert narrowed it down to the patch in question. I was kind of hoping that one of the people that helped introduce the regression would take on some of responsibility to help with the debugging. ;-) I think I have one of the boards that will demonstrate the issue (a Terratec board with xc3028/zl10353), and will try to find some time with the generator once I wrap up the xc4000 work for the PCTV 340e. 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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
> On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
> > > Mauro,
> > >
> > > I've split the revert2.diff that I sent you previously to fix the tuning
> > > regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
> > > that will hopefully allow you to review more easily.
> > >
> > > The first two patches revert their respective changesets and nothing else,
> > > fixing the issue for me.
> > > 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
> > > 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
> > >
> > > The third patch does what I believe is the obvious equivalent fix to
> > > e6a8672631a0 but without the cleanup that breaks tuning on my card.
> > >
> > > Please review and merge
> > >
> > > Signed-off-by: Robert Lowery
> >
> > Mauro,
> >
> > I'm yet to receive a response from you on this clear regression introduced
> > in the 2.6.31 kernel. You attention would be appreciated
> >
> > Thanks
> >
> > -Rob
>
> Robert,
>
> The changes in question (mostly authored by me) are based on
> documentation on what offsets are to be used with the firmware for
> various DVB bandwidths and demodulators. The change was tested by Terry
> on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and
> some other cards I can't remember, using a DVB-T pattern generator for 7
> and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
>
> (Devin,
> Maybe you can double check on the offsets in tuner-xc2028.c with any
> documentation you have available to you?)
>
>
> I haven't been following this thread really at all as the board in the
> subject line was unfamiliar to me, so sorry for any late response or
> dumb questions by me.
>
> May I ask:
>
> 1. what are the exact problem frequencies?
> 2. what is the data source from which you are getting the frequency
> information?
> 3. what does tuner-xc2028 debug logging show as the firmware loaded when
> tune to one of the the problem frequencies?
Robert,
I just found that ACMA has a very nice compilation licensed DTV
transmitters in Australia and their frequencies. Have a look at the
Excel spreadsheet linked on this page:
http://acma.gov.au/WEB/STANDARD/pc=PC_9150
The DTV tab has a list of the Area, callsign, and DTV center freq.
The Glossary tab mentions that DTV broadcasters can have an offset of
+/- 125 kHz from the DTV center freq.
If you could verify that the frequencies you are using for the problem
stations match the list, that would help eliminate commanded tuning
frequency as source of the problem.
Regards,
Andy
> BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
> cxusb_dvico_xc3028_tuner_attach(), this declaration
>
> static struct xc2028_ctrl ctl = {
> .fname = XC2028_DEFAULT_FIRMWARE,
> .max_len = 64,
> .demod = XC3028_FE_ZARLINK456,
> };
>
> really should have ".type = XC2028_AUTO" or ".type = XC2028_D2633", but
> since XC2028_AUTO has a value of 0, it probably doesn't matter.
>
>
> Regards,
> Andy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote: Um, when you say it does the job, what do you mean? It traps the error and prevents the kernel from crashing. The job it was _intended_ to do was to prove that your problems are caused by hardware errors rather than software bugs. If the patch causes the problems to stop, without printing any error messages in the log, then it does indeed prove this. After all, the only places the patch changes any persistent values are after it prints an error message. It did print out error messages: usb 4-2: new full speed USB device using ohci_hcd and address 2 usb 4-2: New USB device found, idVendor=093a, idProduct=2460 usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 4-2: Product: CIF Single Chip usb 4-2: Manufacturer: Pixart Imaging Inc. usb 4-2: configuration #1 chosen from 1 choice [r...@x-linux]:~ # modprobe gspca_pac207 Linux video capture interface: v2.00 gspca: main v2.8.0 registered gspca: probing 093a:2460 pac207: Pixart Sensor ID 0x27 Chips ID 0x09 pac207: Pixart PAC207BCA Image Processor and Control Chip detected (vid/pid 0x093A:0x2460) gspca: video0 created usbcore: registered new interface driver pac207 pac207: registered [r...@x-linux]:~ # capture-example .. capture-example used greatest stack depth: 5848 bytes left [r...@x-linux]:~ # capture-example .ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ...ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 .ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 .ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 ..ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 .ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 c677b800 ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 c677b900 ..ohci_hcd :00:0b.0: Circular hash: 32 c669f8
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Mon, 2010-01-04 at 22:13 -0500, Devin Heitmueller wrote: > Hey Andy, > > On Mon, Jan 4, 2010 at 9:27 PM, Andy Walls wrote: > > The changes in question (mostly authored by me) are based on > > documentation on what offsets are to be used with the firmware for > > various DVB bandwidths and demodulators. The change was tested by Terry > > on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and > > some other cards I can't remember, using a DVB-T pattern generator for 7 > > and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz. > > > > (Devin, > > Maybe you can double check on the offsets in tuner-xc2028.c with any > > documentation you have available to you?) > > At this point the extent to which I've looked in to the issue was > validating that, for a given frequency, the change resulted in a > crappy SNR with lots of BER/UNC errors, and after reverting the change > the signal looked really good with zero BER/UNC. I haven't dug into > *why* it is an issue, but I examined the traces and looked at the > testing methodology and can confirm that there was definitely a > regression and Robert narrowed it down to the patch in question. > > I was kind of hoping that one of the people that helped introduce the > regression would take on some of responsibility to help with the > debugging. ;-) I take responsiblity for the change. However, if fixing a known problem unmasks another problem, then is that a regression? I puzzled over the docs for a while until I had the "Aha!" moment and understood what they were saying. I'm really confident about the freq offset changes - especially since using the wrong center freq in channels.conf is an easy way to mask incorrect freq offsets in the driver module. I'm less confident about the xc3028 firmware segments as extracted and repackaged for linux. I was not involved in that development and I conveniently (for me) assume it is correct -- although that may be an assumption worth challenging. I also do not know the source of the commanded DTV freq's that are in use in the reported problem case. Using the wrong DTV center freq can cause the same problem symptoms as moving the offset used in the tuner-xc2028 module (two wrongs making a right). I just found a nice authoritative Australian source on DTV freq licensees (see my other foloow-up email), so hopefully Robert can double check that. Of course testing with a DVB-T generator instead of a broadcaster's signal would eliminate any doubt about the center freq in use. > I think I have one of the boards that will demonstrate the issue (a > Terratec board with xc3028/zl10353), and will try to find some time > with the generator once I wrap up the xc4000 work for the PCTV 340e. OK, thanks. I have no hardware with which to test. Regards, Andy > Devin -- 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] soc-camera: ov772x: Add buswidth selection flags for platform
This patch remove "buswidth" struct member and add new flags for
ov772x_camera_info.
And it also modify ap325rxa/migor setup.c
Signed-off-by: Kuninori Morimoto
---
arch/sh/boards/mach-ap325rxa/setup.c |4 ++--
arch/sh/boards/mach-migor/setup.c|2 +-
drivers/media/video/ov772x.c | 28
include/media/ov772x.h |7 ---
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index 1f5fa5c..71f556f 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -471,8 +471,8 @@ static struct i2c_board_info ap325rxa_i2c_camera[] = {
};
static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
- .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
+ .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP | \
+ OV772X_FLAG_8BIT,
.edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
};
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 507c77b..9b4676f 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -431,7 +431,7 @@ static struct i2c_board_info migor_i2c_camera[] = {
};
static struct ov772x_camera_info ov7725_info = {
- .buswidth = SOCAM_DATAWIDTH_8,
+ .flags = OV772X_FLAG_8BIT,
};
static struct soc_camera_link ov7725_link = {
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3a45e94..12cb66f 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -547,7 +547,6 @@ static const struct v4l2_queryctrl ov772x_controls[] = {
},
};
-
/*
* general function
*/
@@ -634,9 +633,18 @@ static unsigned long ov772x_query_bus_param(struct
soc_camera_device *icd)
struct soc_camera_link *icl = to_soc_camera_link(icd);
unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | priv->info->buswidth;
+ SOCAM_DATA_ACTIVE_HIGH;
+
+ if (priv->info->flags & OV772X_FLAG_8BIT)
+ flags |= SOCAM_DATAWIDTH_8;
+
+ if (priv->info->flags & OV772X_FLAG_10BIT)
+ flags |= SOCAM_DATAWIDTH_10;
- return soc_camera_apply_sensor_flags(icl, flags);
+ if (flags & SOCAM_DATAWIDTH_MASK)
+ return soc_camera_apply_sensor_flags(icl, flags);
+
+ return 0;
}
static int ov772x_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
@@ -1040,15 +1048,6 @@ static int ov772x_video_probe(struct soc_camera_device
*icd,
return -ENODEV;
/*
-* ov772x only use 8 or 10 bit bus width
-*/
- if (SOCAM_DATAWIDTH_10 != priv->info->buswidth &&
- SOCAM_DATAWIDTH_8 != priv->info->buswidth) {
- dev_err(&client->dev, "bus width error\n");
- return -ENODEV;
- }
-
- /*
* check and show product ID and manufacturer ID
*/
pid = i2c_smbus_read_byte_data(client, PID);
@@ -1130,7 +1129,6 @@ static int ov772x_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov772x_priv*priv;
- struct ov772x_camera_info *info;
struct soc_camera_device *icd = client->dev.platform_data;
struct i2c_adapter*adapter = to_i2c_adapter(client->dev.parent);
struct soc_camera_link*icl;
@@ -1145,8 +1143,6 @@ static int ov772x_probe(struct i2c_client *client,
if (!icl || !icl->priv)
return -EINVAL;
- info = icl->priv;
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(&adapter->dev,
"I2C-Adapter doesn't support "
@@ -1158,7 +1154,7 @@ static int ov772x_probe(struct i2c_client *client,
if (!priv)
return -ENOMEM;
- priv->info = info;
+ priv->info = icl->priv;
v4l2_i2c_subdev_init(&priv->subdev, client, &ov772x_subdev_ops);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 14c77ef..7e83745 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -15,8 +15,10 @@
#include
/* for flags */
-#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
-#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+#define OV772X_FLAG_VFLIP (1 << 0) /* Vertical flip image */
+#define OV772X_FLAG_HFLIP (1 << 1) /* Horizontal flip image */
+#define OV772X_FLAG_8BIT (1 << 2) /* 8bit buswidth */
+#define OV772X_FLAG_10BIT (1 << 3) /* 10bit buswidth */
/*
* for Edge ctrl
@@ -53,7 +55,6 @@ struct ov772x_edge_ctrl {
* ov772x camera info
*/
struct ov772x_camera_info {
- unsigned long buswi
Re: [linux-dvb] siano firmware and behaviour after resuming power
On Thu, 2009-12-03 at 14:38 +0100, Luca Olivetti wrote: > En/na BOUWSMA Barry ha escrit: > > >> I found a something here > >> > >> http://marc.info/?l=linux-usb-users&m=116827193506484&w=2 > >> > >> that purportedly resets an usb device. > >> What I tried was, before powering off: > >> > >> 1) unload the drivers > >> 2) use the above to reset the stick > >> 3) power off > >> > >> and, before loading the drivers, issue a reset again. > >> Sometimes it works, sometimes it doesn't, the end result is that I cannot > >> leave the device plugged-in if I want to use it. I've also got a siano card, but in my case it's embedded in my Dell laptop, so yanking it out and plugging it back in isn't even an option. The card is however a USB device and I've included the lsusb -v output at the end in case it's useful. I've tried the firmware you're referring too, but there's also a request for sms1xxx-nova-b-dvbt-01.fw in the dmesg and this is asked for first (in my case), with a siano supplied one sought if it can't find this first one. I'm not having problems with cold restarts, but suspend/hibernate sees the things go bad on resume. I've added some stuff to /etc/pm/sleep.d which unloads the modules and then reloads then on resume. It's a simple script: #!/bin/bash case $1 in hibernate) echo "Suspending to disk" modprobe -r smsdvb modprobe -r smsusb ;; suspend) echo "Suspending to RAM" modprobe -r smsdvb modprobe -r smsusb ;; thaw) echo "Suspend to disk is over, Resuming..." modprobe smsdvb modprobe smsusb ;; resume) echo "Suspend to RAM is over, Resuming..." modprobe smsdvb modprobe smsusb ;; *) echo "somebody is calling me totally wrong." ;; esac This addresses these problems for me. You might be able to add something similar to /etc/pm/power.d to unload modules to address the problem. Rodd Bus 001 Device 003: ID 2040:1801 Hauppauge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x2040 Hauppauge idProduct 0x1801 bcdDevice0.01 iManufacturer 1 Hauppauge Computer Works iProduct2 WinTV-NOVA iSerial 3 f05eb5ec bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) -- 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
