Re: [PATCH] Add support for Zolid Hybrid PCI card
On Tue, Sep 08, 2009 at 05:57:12PM -0400, Michael Krufky wrote:
Hi Mike,
Henk,
Why do you expect a 8295? If your board uses the SAA7131, then we
would expect an 8290 IF demod.
Ah, I just checked the history of this email thread -- I must have
read one of your previous emails too quickly. :-) Perhaps there is a
typo in the document that you read -- tda8290 is correct.
About the analog noise and quality issues that you report, perhaps
there is some tweaking that can be done to help the situation. I dont
have that Zolid board, myself, so I can't reallt help much in that
respect, unfortunately.
At this point, I feel that your patch is fine to merge into the
development repository, although I have some small cleanup requests:
#1) You can omit this line from the tda18271_config struct:
.config = 0, /* no AGC config */
This is not necessary, as it is initialized at zero and this serves no
purpose even for documentation's sake.
#2) The configuration inside saa7134-cards.c should be moved to the
end of the boards array.
#3) The configuration case inside saa7134-dvb.c should be moved to the
end of the switch..case block.
I'll wait for these cleanups, then I have no issue pushing up your
patch. Any quality improvements that we find along the way can
certainly be added afterwards.
Good work.
Regards,
Mike
Hi Mike,
Did the last cleanups.
Good review! Thank you for your help.
- henk
- patch comment -
Adds support for Zolid Hybrid PCI card:
http://linuxtv.org/wiki/index.php/Zolid_Hybrid_TV_Tuner
test status analog (PAL-B):
- Sometimes picture is noisy, but it becomes crystal clear after
switching between channels. (happens for example at 687.25 Mhz)
- On a lower frequency (511.25 Mhz) the picture is always sharp, but
lacks colour.
- No sound problems.
- radio untested.
Digital:
- DVB-T/H stream reception works.
- Would expect to see some more channels in the higher frequency region.
Overall is the impression that sensitivity still needs improvement
both in analog and digital modes.
Signed-off-by: henk.vergo...@gmail.com
diff -r 2b49813f8482 linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Sep 03 09:06:34
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Sep 09 07:47:10
2009 +0200
@@ -5296,6 +5296,27 @@
.amux = TV,
},
},
+ [SAA7134_BOARD_ZOLID_HYBRID_PCI] = {
+ .name = Zolid Hybrid TV Tuner PCI,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 0,
+ .mpeg = SAA7134_MPEG_DVB,
+ .ts_type= SAA7134_MPEG_TS_PARALLEL,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }},
+ .radio = { // untested
+ .name = name_radio,
+ .amux = TV,
+ },
+ },
};
@@ -6429,6 +6450,12 @@
.subdevice= 0x0138, /* LifeView FlyTV Prime30 OEM */
.driver_data = SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= PCI_VENDOR_ID_PHILIPS,
+ .subdevice= 0x2004,
+ .driver_data = SAA7134_BOARD_ZOLID_HYBRID_PCI,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff -r 2b49813f8482 linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Thu Sep 03 09:06:34
2009 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Wed Sep 09 07:47:10
2009 +0200
@@ -1013,6 +1013,22 @@
.probe_tuner = TDA829X_DONT_PROBE,
};
+static struct tda10048_config zolid_tda10048_config = {
+ .demod_address= 0x10 1,
+ .output_mode = TDA10048_PARALLEL_OUTPUT,
+ .fwbulkwritelen = TDA10048_BULKWRITE_200,
+ .inversion= TDA10048_INVERSION_ON,
+ .dtv6_if_freq_khz = TDA10048_IF_3300,
+ .dtv7_if_freq_khz = TDA10048_IF_3500,
+ .dtv8_if_freq_khz = TDA10048_IF_4000,
+ .clk_freq_khz = TDA10048_CLK_16000,
+ .disable_gate_access = 1,
+};
+
+static struct tda18271_config zolid_tda18271_config = {
+ .gate= TDA18271_GATE_ANALOG,
+};
+
/* ==
* Core code
*/
@@ -1492,6 +1508,19 @@
Re: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
Morvan Le Meut a écrit : i can use the remote now ( using devinput in lirc ) but a few quirks remains : - dmesg gives a lot of saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=1 - in irw most keys are misidentified ( Power as RECORD, Mute as Menu, Down as DVD and DVD is correctly identified ) i guess using ir_codes_adstech_dvb_t_pci was not such a bright idea after all :p ( i included a full dmesg output ) For now, it is enough work on my part, i'll try to correct those keycodes later. It is amazing what you can do even when you don't understand most of it :D . Working on it, but i don't think everything is correct : some totaly unrelated keys have the same keycode. For example Jump and Volume+ or Search and Volume-. Beside, i keep getting Sep 9 10:17:16 debian kernel: [ 2029.892014] saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=0 Sep 9 10:17:16 debian kernel: [ 2029.944029] saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=1 for each recognized keypress I'll need a lot of help there : i don't know what to do. -- 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
i tried to load the saa7134 module with ir_debug=1 and removed all keycodes in ir-keymaps.c , here is what i got after pressing the buttons (left to right then going down on the remote ): (power) Sep 9 10:43:41 debian kernel: [ 3615.060015] saa7133[0]/ir: build_key gpio=0x1b mask=0x7f data=27 Sep 9 10:43:41 debian kernel: [ 3615.112017] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (mute) Sep 9 10:43:44 debian kernel: [ 3618.440021] saa7133[0]/ir: build_key gpio=0x1f mask=0x7f data=31 Sep 9 10:43:44 debian kernel: [ 3618.492019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (1) Sep 9 10:50:42 debian kernel: [ 4036.796017] saa7133[0]/ir: build_key gpio=0x17 mask=0x7f data=23 Sep 9 10:50:43 debian kernel: [ 4036.900019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (2) Sep 9 10:51:14 debian kernel: [ 4068.776014] saa7133[0]/ir: build_key gpio=0xf mask=0x7f data=15 Sep 9 10:51:14 debian kernel: [ 4068.828017] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (3) Sep 9 10:51:36 debian kernel: [ 4090.408016] saa7133[0]/ir: build_key gpio=0x13 mask=0x7f data=19 Sep 9 10:51:36 debian kernel: [ 4090.460020] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (4) Sep 9 10:51:47 debian kernel: [ 4101.380016] saa7133[0]/ir: build_key gpio=0x16 mask=0x7f data=22 Sep 9 10:51:47 debian kernel: [ 4101.432019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (5) Sep 9 10:52:00 debian kernel: [ 4114.068019] saa7133[0]/ir: build_key gpio=0xe mask=0x7f data=14 Sep 9 10:52:00 debian kernel: [ 4114.120020] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (6) Sep 9 10:52:15 debian kernel: [ 4129.672020] saa7133[0]/ir: build_key gpio=0x1e mask=0x7f data=30 Sep 9 10:52:15 debian kernel: [ 4129.776019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (7) Sep 9 10:52:34 debian kernel: [ 4148.132020] saa7133[0]/ir: build_key gpio=0x14 mask=0x7f data=20 Sep 9 10:52:34 debian kernel: [ 4148.236020] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (8) Sep 9 10:52:49 debian kernel: [ 4163.160020] saa7133[0]/ir: build_key gpio=0xc mask=0x7f data=12 Sep 9 10:52:49 debian kernel: [ 4163.212022] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (9) Sep 9 10:53:02 debian kernel: [ 4176.056016] saa7133[0]/ir: build_key gpio=0x1c mask=0x7f data=28 Sep 9 10:53:02 debian kernel: [ 4176.108017] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (jump) Sep 9 10:48:56 debian kernel: [ 3930.144021] saa7133[0]/ir: build_key gpio=0x15 mask=0x7f data=21 Sep 9 10:48:56 debian kernel: [ 3930.196019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (0) Sep 9 10:56:55 debian kernel: [ 4409.016020] saa7133[0]/ir: build_key gpio=0xd mask=0x7f data=13 Sep 9 10:56:55 debian kernel: [ 4409.068023] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (search) Sep 9 10:57:05 debian kernel: [ 4419.520021] saa7133[0]/ir: build_key gpio=0x1d mask=0x7f data=29 Sep 9 10:57:05 debian kernel: [ 4419.624019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (guide) Sep 9 10:57:14 debian kernel: [ 4428.568017] saa7133[0]/ir: build_key gpio=0x17 mask=0x7f data=23 Sep 9 10:57:14 debian kernel: [ 4428.620017] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (up arrow) Sep 9 10:57:20 debian kernel: [ 4434.236015] saa7133[0]/ir: build_key gpio=0xf mask=0x7f data=15 Sep 9 10:57:20 debian kernel: [ 4434.340019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (menu) Sep 9 10:57:29 debian kernel: [ 4443.180017] saa7133[0]/ir: build_key gpio=0x1f mask=0x7f data=31 Sep 9 10:57:29 debian kernel: [ 4443.232019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (left arrow) Sep 9 10:57:41 debian kernel: [ 4455.504014] saa7133[0]/ir: build_key gpio=0x16 mask=0x7f data=22 Sep 9 10:57:41 debian kernel: [ 4455.556015] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (enter) Sep 9 10:57:50 debian kernel: [ 4464.604018] saa7133[0]/ir: build_key gpio=0xe mask=0x7f data=14 Sep 9 10:57:50 debian kernel: [ 4464.656017] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (right arrow) Sep 9 10:58:02 debian kernel: [ 4476.668018] saa7133[0]/ir: build_key gpio=0x1e mask=0x7f data=30 Sep 9 10:58:02 debian kernel: [ 4476.772019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (info) Sep 9 10:58:12 debian kernel: [ 4485.976016] saa7133[0]/ir: build_key gpio=0x1a mask=0x7f data=26 Sep 9 10:58:12 debian kernel: [ 4486.028018] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (down arrow) Sep 9 10:58:21 debian kernel: [ 4494.920015] saa7133[0]/ir: build_key gpio=0x6 mask=0x7f data=6 Sep 9 10:58:21 debian kernel: [ 4495.024019] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127 (exit) Sep 9 10:58:30 debian kernel: [ 4504.332020] saa7133[0]/ir: build_key gpio=0x12 mask=0x7f data=18 Sep 9 10:58:30 debian kernel: [ 4504.384020] saa7133[0]/ir: build_key gpio=0x7f mask=0x7f data=127
Re: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
On Wed, 09 Sep 2009 10:31:46 +0200, Morvan Le Meut mlem...@gmail.com wrote: Morvan Le Meut a écrit : i can use the remote now ( using devinput in lirc ) but a few quirks remains : - dmesg gives a lot of saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=1 - in irw most keys are misidentified ( Power as RECORD, Mute as Menu, Down as DVD and DVD is correctly identified ) i guess using ir_codes_adstech_dvb_t_pci was not such a bright idea after all :p ( i included a full dmesg output ) For now, it is enough work on my part, i'll try to correct those keycodes later. It is amazing what you can do even when you don't understand most of it :D . Working on it, but i don't think everything is correct : some totaly unrelated keys have the same keycode. For example Jump and Volume+ or Search and Volume-. Beside, i keep getting Sep 9 10:17:16 debian kernel: [ 2029.892014] saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=0 Sep 9 10:17:16 debian kernel: [ 2029.944029] saa7134 IR (ADS Tech Instant TV: unknown key: key=0x7f raw=0x7f down=1 for each recognized keypress I'll need a lot of help there : i don't know what to do. I think that correct gpio mask in saa7134-input.c would give unique keycodes for every keypress. It's most likely that you need to invent new gpio mask, but I'm not sure about this: (http://linuxtv.org/wiki/index.php/Remote_controllers-V4L#How_to_add_remote_control_support_to_a_card_.28GPIO_remotes.29) I'm sorry that I can't help you any further, it's getting far beyond my knowledge. I'm leaving this to somebody else... -- 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
ZC0301 webcam not working
Hello, My webcam used to work with the spca5xx driver from mxhaard.free.fr. It neither work with the gspca driver built into Debian sid, nor with the upstream version from hg http://linuxtv.org/hg/~jfrancois/gspca/. However /dev/video0 is created. Can someone help making it work? Here is information gathered on Debian sid 2.6.30 kernel using the uptodate linuxtv upstream version. Thanks, Guillaume lsusb -v Bus 002 Device 002: ID 0ac8:301b Z-Star Microelectronics Corp. ZC0301 Webcam Environement: debian sid + uptodate upstream version from hg http://linuxtv.org/hg/~jfrancois/gspca/ uname -a Linux dex 2.6.30-1-686 #1 SMP Sat Aug 15 19:11:58 UTC 2009 i686 GNU/Linux modprobe gspca_main debug=2000 [ 2741.696129] usb 2-1: new full speed USB device using uhci_hcd and address 2 [ 2741.892219] usb 2-1: New USB device found, idVendor=0ac8, idProduct=301b [ 2741.892226] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2741.892231] usb 2-1: Product: PC Camera [ 2741.892235] usb 2-1: Manufacturer: Z-Star Corp. [ 2741.892385] usb 2-1: configuration #1 chosen from 1 choice [ 2742.031834] Linux video capture interface: v2.00 [ 2742.072120] gspca: main v2.7.0 registered [ 2742.075823] gspca: probing 0ac8:301b [ 2742.203227] zc3xx: probe sensor - 0004 [ 2742.203232] zc3xx: Find Sensor CS2102 [ 2742.207324] gspca: probe ok [ 2742.207359] usbcore: registered new interface driver zc3xx [ 2742.207364] zc3xx: registered [ 3375.544635] usbcore: deregistering interface driver zc3xx [ 3375.544753] gspca: disconnect complete [ 3375.544780] zc3xx: deregistered [ 3377.010799] gspca: main deregistered [ 3395.515948] gspca: main v2.7.0 registered [ 3406.738478] gspca: main deregistered [ 3411.609437] gspca: main v2.7.0 registered [ 3417.706804] gspca: main deregistered [ 3424.648535] gspca: main v2.7.0 registered modprobe gspca_zc3xx [ 3489.682812] zc3xx: reg w [] = 01 [ 3489.684423] zc3xx: reg w [0010] = 00 [ 3489.685429] zc3xx: reg w [0001] = 01 [ 3489.686445] zc3xx: reg w [0012] = 03 [ 3489.687424] zc3xx: reg w [0012] = 01 [ 3489.717419] zc3xx: i2c w [01] = 00aa (00) [ 3489.751456] zc3xx: i2c r [01] - (00) [ 3489.751461] zc3xx: reg w [] = 01 [ 3489.752433] zc3xx: reg w [0010] = 04 [ 3489.753424] zc3xx: reg w [0001] = 01 [ 3489.754421] zc3xx: reg w [0012] = 03 [ 3489.755427] zc3xx: reg w [0012] = 01 [ 3489.781441] zc3xx: i2c w [01] = 00aa (00) [ 3489.815457] zc3xx: i2c r [01] - 0045 (00) [ 3489.815464] zc3xx: reg w [0010] = 04 [ 3489.817456] zc3xx: reg r [0010] - 04 [ 3489.817461] zc3xx: reg w [] = 01 [ 3489.818449] zc3xx: reg w [] = 01 [ 3489.819581] usbcore: registered new interface driver zc3xx [ 3489.845093] gspca main driver: VIDIOC_QUERYCAP driver=zc3xx, card=PC Camera, bus=usb-:00:1d.0-1, version=0x00020700, capabilities=0x0501 output of gspca/v4l2-apps/test/driver-test driver=zc3xx, card=PC Camera, bus=usb-:00:1d.0-1, version=2.7.0, capabilities=CAPTURE READWRITE STREAMING enum_stds: Invalid argument Error! Driver is not reporting supported STD, frames/sec and number of lines! Trying to continue anyway... INPUT: index=0, name=zc3xx, type=2, audioset=0, tuner=0, std=, status=0 FORMAT: index=0, type=1, flags=1, description='JPEG' fourcc=JPEG FMT SET: 640x480, fourcc=JPEG, 640 bytes/line, 115790 bytes/frame, colorspace=0x0007 PARM: capability=0, capturemode=0, nan fps ext=0, readbuf=2 g_tuner: Invalid argument Assuming 62.5 kHz step 62.5 kHz step s_frequency: Invalid argument g_tuner: Invalid argument Assuming 62.5 kHz step 62.5 kHz step s_frequency: Invalid argument g_tuner: Invalid argument Assuming 62.5 kHz step 62.5 kHz step s_frequency: Invalid argument Preparing for frames... REQBUFS: count=2, type=video-cap, memory=mmap QUERYBUF: 00:00:00. index=0, type=video-cap, bytesused=0, flags=0x, field=none, sequence=0, memory=mmap, offset=0x, length=118784 TIMECODE: 00:00:00 type=0, flags=0x, frames=0, userbits=0x QUERYBUF: ERROR: VIDIOC_S_FMT said buffer should have 115790 size, but received 118784 from QUERYBUF! QUERYBUF: 00:00:00. index=1, type=video-cap, bytesused=0, flags=0x, field=none, sequence=0, memory=mmap, offset=0x0001d000, length=118784 TIMECODE: 00:00:00 type=0, flags=0x, frames=0, userbits=0x QUERYBUF: ERROR: VIDIOC_S_FMT said buffer should have 115790 size, but received 118784 from QUERYBUF! Activating 2 queues QBUF: 00:00:00. index=0, type=video-cap, bytesused=0, flags=0x0002, field=any, sequence=0, memory=mmap, offset=0x, length=0 TIMECODE: 00:00:00 type=0, flags=0x, frames=0, userbits=0x QBUF: 00:00:00. index=1, type=video-cap, bytesused=0, flags=0x0002, field=any, sequence=0, memory=mmap, offset=0x, length=0 TIMECODE: 00:00:00 type=0, flags=0x, frames=0, userbits=0x Enabling streaming Waiting for frames... select timeout dmesg after end of
Re: [PATCHv15 7/8] FM TX: si4713: Add Kconfig and Makefile entries
On Sat, 2009-08-08 at 13:10 +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: Simple add Makefile and Kconfig entries. ... + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This module is the v4l2 radio ^^^ These should be RDS and RBDS? Cheers, Matti A. -- 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
Nova-T 500 Dual DVB-T and h.264
Hi, Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T broadcasts with h.264 and AAC audio? DTT in New Zealand uses these formats and I'm seeing poor performance from the Nova-T card. My thinking is that it was probably not conceived for dealing with dual h264 streams. Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if this card might have better performance. Thanks, Lou -- 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
just out of curiosity, what's the difference between case SAA7134_BOARD_ADS_INSTANT_TV: dev-has_remote = SAA7134_REMOTE_GPIO; break; and case SAA7134_BOARD_FLYDVBS_LR300: saa_writeb(SAA7134_GPIO_GPMODE3, 0x80); saa_writeb(SAA7134_GPIO_GPSTATUS2, 0x40); dev-has_remote = SAA7134_REMOTE_GPIO; break; ? could it be that the repeating keys come from not using that saa_writeb thing ? Morvan Le Meut a écrit : wait, from that webpage, the gpio would be different for each key, independently from the mask, so my previous attempt with ir_debug=1 means that the gpio itself is read incorrectly .. :( -- 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: xf86-video-v4l
On Wed, Sep 9, 2009 at 8:53 AM, Domenico Andreolicav...@gmail.com wrote: hi, On Wed, Sep 09, 2009 at 12:17:49AM -0400, CityK wrote: Stefan Sassenberg wrote: what does the xf86-video-v4l driver do? I think I know the purpose of xf86-video-graphics_card drivers, but I don't know what the -v4l does. How is it used? Anyway, in answer to your question: * from the command line, type man v4l Then supplement that info with the following points taken from the V4L2 API i think he knows also what v4l is about. he was asking which kind of support is given to X through this driver, something i'm also curious to know. cheers, Domenico Domenico, Try man v4l as CityK suggested -- you will find that he did in fact answer the question appropriately. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
NetUP Dual DVB-T/C-CI RF PCI-E x1
Hello, We have designed NetUP Dual NetUP Dual DVB-T/C-CI RF PCI-E x1 card. A short description is available in wiki - http://linuxtv.org/wiki/index.php/NetUP_Dual_DVB_T_C_CI_RF Features: * PCI-e x1 * Supports two DVB-T/DVB-C transponders simultaneously * Supports two analog audio/video channels simultaneously * Independent descrambling of two transponders * Hardware PID filtering Now we have started the work on the driver for Linux. The following components used in this card already have their code for Linux published: * Conexant CX23885, CX25840 * Xceive XC5000 silicon TV tuner We are working on the code for the following components: * STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver * Altera FPGA for Common Interafce. We have developed FPGA firmware for CI (according to PCMCIA/en50221). Also we are doing hardware PID filtering. It's fast and very flexible. JTAG is used for firmware uploading into FPGA - this part contains JAM player from Altera for processing JAM STAPL Byte-Code (.jbc files). The resulting code will be published under GPL after receiving permissions from IC vendors. -- Abylai Ospan aos...@netup.ru NetUP Inc. P.S. We will show this card at the upcoming IBC exhibition ( stand IP402 ). -- 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: Invalid module format
On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquezanimatri...@gmail.com wrote: Hello, I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. The compilation of v4l-dvb works well (the kernel which is chosen is the right), but when I try to modprobe em28xx, I get this : WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videodev.ko): Invalid module format WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/common/ir-common.ko): Invalid module format FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format I have this error in my dmesg : [ 3903.465920] tveeprom: disagrees about version of symbol module_layout I join my .config file. What do I need to do ? Thanks! Usually this occurs when people are using the mrechberger version of the em28xx driver, and the symbols are in conflict with the rest of the v4l-dvb tree. You need to either switch to the v4l-dvb version of the driver (removing the .ko files for the mrec driver), or recompile and reinstall the mrec driver *after* you've installed the latest v4l-dvb code. 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
Samuel Rakitnican a écrit : No, this is used for some autodetection routine for different version of the same card. This has nothing to do with your case. The key is here, you need to find correct value. case SAA7134_BOARD_ADS_INSTANT_TV: ir_codes = AdsInstantTvPci_codes; // This remote seems to return 0x7f after each button is pushed. // No button may be repeated ; no release message. Only 1 msg with // raw data = button idx, followed by one message with raw data = 0x7f mask_keycode = 0xff; mask_keyup = 0xff; mask_keydown = 0xff; polling = 50; // ms break; Have you tried to follow the tutorial on the web?, By tutorial you need to modify with something like this: case SAA7134_BOARD_ADS_INSTANT_TV: ir_codes = AdsInstantTvPci_codes; mask_keycode = 0; polling = 50; // ms break; And then try to find correct gpio masks. i did try it ( well, i left the keyup and keydown part and i also tried it by setting it to 0 ) but the gpio still repeat (saa7133[0]/ir: build_key gpio=0x1b mask=0x0 data=0 for Power and Record, each followed by gpio=7f ). Which is why i believe i am missing part of that code ( got the dvb-t version too on another computer, and given the software used, there should be no duplicate keys ). I guess i will have to wait for someone to solve the problem. I can at least use the remote in a broken way. -- 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: Nova-T 500 Dual DVB-T and h.264
Lou Otway lotway at nildram.co.uk writes: Hi, Does anyone have experience of using the Hauppuage Nova-T 500 with DVB-T broadcasts with h.264 and AAC audio? DTT in New Zealand uses these formats and I'm seeing poor performance from the Nova-T card. My thinking is that it was probably not conceived for dealing with dual h264 streams. Has the PCIe HVR-2200 been tested with dual h.264? I was wondering if this card might have better performance. Thanks, Lou -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, AFAIK the card just tunes to the desired frequency, applies configured filters (to select the desired station through its PID number), and handles the received transport stream to the calling application. It's up to the lastest to properly decode it. Check that the software you are using is properly capable of decoding this kind of content. Best regards, Eduard Huguet -- 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: Invalid module format
On Wed, Sep 9, 2009 at 2:13 PM, animatri...@gmail.comanimatri...@gmail.com wrote: Without mrechberger version, I can't find support for my Pinnacle PCTV Usb stick. If I had it, (after having installed the mrec driver), I have this error : [ 909.128197] em28xx v4l2 driver version 0.0.1 loaded [ 909.128518] em28xx: new video device (eb1a:2870): interface 0, class 255 [ 909.128521] em28xx: device is attached to a USB 2.0 bus [ 909.128525] em28xx #0: Alternate settings: 8 [ 909.128527] em28xx #0: Alternate setting 0, max size= 0 [ 909.128530] em28xx #0: Alternate setting 1, max size= 0 [ 909.128532] em28xx #0: Alternate setting 2, max size= 1448 [ 909.128535] em28xx #0: Alternate setting 3, max size= 2048 [ 909.128537] em28xx #0: Alternate setting 4, max size= 2304 [ 909.128540] em28xx #0: Alternate setting 5, max size= 2580 [ 909.128543] em28xx #0: Alternate setting 6, max size= 2892 [ 909.128545] em28xx #0: Alternate setting 7, max size= 3072 [ 909.545514] input: em2880/em2870 remote control as /class/input/input12 [ 909.545548] em28xx-input.c: remote control handler attached [ 909.545551] em28xx #0: Found Pinnacle PCTV DVB-T [ 909.545571] usbcore: registered new interface driver em28xx [ 909.595321] em28xx_dvb: Unknown symbol em28xx_set_mode [ 909.595461] em28xx_dvb: Unknown symbol em28xx_uninit_isoc [ 909.595547] em28xx_dvb: Unknown symbol em28xx_init_isoc [ 909.595678] em28xx_dvb: disagrees about version of symbol em28xx_unregister_extension [ 909.595681] em28xx_dvb: Unknown symbol em28xx_unregister_extension [ 909.596137] em28xx_dvb: disagrees about version of symbol em28xx_register_extension [ 909.596140] em28xx_dvb: Unknown symbol em28xx_register_extension [ 909.596355] em28xx_dvb: Unknown symbol em28xx_tuner_callback What should I do ? Thanks! snip If you built mrec's driver from source, it may not have picked up the latest v4l headers. If you are trying to use his binary package, then you have to use whatever kernel he compiled it against (and you cannot install the latest v4l-dvb tree). Assuming you're talking about the model 70e, I have a tree setup for that device, but it's not yet fully debugged: http://www.kernellabs.com/hg/~dheitmueller/pctv-70e 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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Sep 9 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12711:13c47deee3b1 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc8-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc8-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc8-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS 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: WARNINGS linux-2.6.31-rc8-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc8-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc8-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS 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: WARNINGS linux-2.6.31-rc8-x86_64: WARNINGS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc8): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS 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: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Invalid module format
On Wed, Sep 9, 2009 at 2:34 PM, animatri...@gmail.com animatri...@gmail.com wrote: I have this error, when I load the module : [ 2122.708062] em28xx: Unknown symbol v4l2_i2c_new_probed_subdev [ 2122.708402] em28xx: disagrees about version of symbol v4l2_i2c_subdev_addr [ 2122.708404] em28xx: Unknown symbol v4l2_i2c_subdev_addr [ 2122.708680] em28xx: disagrees about version of symbol video_devdata [ 2122.708682] em28xx: Unknown symbol video_devdata [ 2122.708889] em28xx: Unknown symbol v4l_bound_align_image [ 2122.709594] em28xx: disagrees about version of symbol video_unregister_device [ 2122.709597] em28xx: Unknown symbol video_unregister_device [ 2122.709810] em28xx: disagrees about version of symbol video_device_alloc [ 2122.709813] em28xx: Unknown symbol video_device_alloc [ 2122.709886] em28xx: disagrees about version of symbol v4l2_device_disconnect [ 2122.709888] em28xx: Unknown symbol v4l2_device_disconnect [ 2122.709982] em28xx: disagrees about version of symbol video_register_device [ 2122.709985] em28xx: Unknown symbol video_register_device [ 2122.710090] em28xx: disagrees about version of symbol v4l2_device_register [ 2122.710093] em28xx: Unknown symbol v4l2_device_register [ 2122.710416] em28xx: Unknown symbol ir_codes_evga_indtube [ 2122.711104] em28xx: disagrees about version of symbol v4l2_device_unregister [ 2122.711106] em28xx: Unknown symbol v4l2_device_unregister [ 2122.711332] em28xx: disagrees about version of symbol video_device_release [ 2122.711335] em28xx: Unknown symbol video_device_release [ 2122.711406] em28xx: disagrees about version of symbol v4l2_i2c_new_subdev [ 2122.711408] em28xx: Unknown symbol v4l2_i2c_new_subdev Is it because of my (wrong) configuration or your code (debug) ? Thanks ! (It seems that the mailing list is not working ) snip Please stop top posting. Did you build mrec's driver from source? Or are you using a binary package? If you built it from source, then your problem has to do with his code not finding the proper headers. If you are using his binary package, then you need to understand that the binary package only works with whatever kernel he built against. Either way, this is a problem with your environment and not with the v4l-dvb code. I'm not really in a position to help you debug problems getting mrec's driver to work. 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: Invalid module format
On Wed, Sep 9, 2009 at 6:19 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 12:14 PM, Edouard Marquezanimatri...@gmail.com wrote: Hello, I am using Gentoo with tuxonice-sources-2.6.3.0-r5 that is to say 2.6.30.5. The compilation of v4l-dvb works well (the kernel which is chosen is the right), but when I try to modprobe em28xx, I get this : WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format WARNING: Error inserting videobuf_vmalloc (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-vmalloc.ko): Invalid module format WARNING: Error inserting v4l2_compat_ioctl32 (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-compat-ioctl32.ko): Invalid module format WARNING: Error inserting v4l1_compat (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videodev.ko): Invalid module format WARNING: Error inserting v4l2_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/v4l2-common.ko): Invalid module format WARNING: Error inserting ir_common (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/common/ir-common.ko): Invalid module format FATAL: Error inserting em28xx (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/em28xx/em28xx.ko): Invalid module format I have this error in my dmesg : [ 3903.465920] tveeprom: disagrees about version of symbol module_layout I join my .config file. What do I need to do ? Thanks! Usually this occurs when people are using the mrechberger version of the em28xx driver, and the symbols are in conflict with the rest of the v4l-dvb tree. this is not true my old driver which is not available anymore did not ship any other modules aside the em28xx driver itself. This is a video4linux issue and has nothing to do with it. Best Regards, Markus -- 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: Invalid module format
On Wed, Sep 9, 2009 at 9:09 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: On Wed, Sep 9, 2009 at 3:02 PM, Markus Rechbergermrechber...@gmail.com wrote: this is not true my old driver which is not available anymore did not ship any other modules aside the em28xx driver itself. This is a video4linux issue and has nothing to do with it. Best Regards, Markus Hello Marks, While it is true that your driver did not include anything other than em28xx, I assume it is compiled against a certain set of v4l2 headers, and if those headers change (such as changes to data structures), then the em28xx modules you distributed would not work with that version of the v4l2 modules. I stopped the work at around Oct last year, 2.6.27 is the latest kernel which is supposed to be supported with it. Although since there are some bad bugs in it which I've been told by the manufacturer afterwards I do not recommend to use it either it shortens the lifetime of most devices... Best is to stick with windows unless the manufacturer and chipdesigners support a driver. WARNING: Error inserting videobuf_core (/lib/modules/2.6.30-tuxonice- r5/kernel/drivers/media/video/videobuf-core.ko): Invalid module format this is something that cannot be caused by the em28xx work, it's any other messy issue with the v4l2 kernel API. Markus If he wants to use your driver, I would assume he would need to reinstall the stock kernel (overwriting whatever locally built version of v4l-dvb he previously installed). 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: (Saa7134) Re: ADS-Tech Instant TV PCI, no remote support
I don't know if i mentioned it before but something i find strange is saa7134 IR (ADS Tech Instant TV: unknown key: key=0x00 raw=0x00 down=1 as soon as the module is loaded. Morvan Le Meut a écrit : i did try it ( well, i left the keyup and keydown part and i also tried it by setting it to 0 ) but the gpio still repeat (saa7133[0]/ir: build_key gpio=0x1b mask=0x0 data=0 for Power and Record, each followed by gpio=7f ). Which is why i believe i am missing part of that code ( got the dvb-t version too on another computer, and given the software used, there should be no duplicate keys ). I guess i will have to wait for someone to solve the problem. I can at least use the remote in a broken way. -- 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: xf86-video-v4l
On Wed, Sep 09, 2009 at 11:12:45AM -0400, Michael Krufky wrote: On Wed, Sep 9, 2009 at 8:53 AM, Domenico Andreolicav...@gmail.com wrote: hi, On Wed, Sep 09, 2009 at 12:17:49AM -0400, CityK wrote: Stefan Sassenberg wrote: what does the xf86-video-v4l driver do? I think I know the purpose of xf86-video-graphics_card drivers, but I don't know what the -v4l does. How is it used? Anyway, in answer to your question: * from the command line, type man v4l Then supplement that info with the following points taken from the V4L2 API i think he knows also what v4l is about. he was asking which kind of support is given to X through this driver, something i'm also curious to know. cheers, Domenico Domenico, Try man v4l as CityK suggested -- you will find that he did in fact answer the question appropriately. indeed :) i saw the pointers to the V4L api reference and supposed he was explaining what V4L is... thank you, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- 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/2] stv06xx webcams with HDCS 1xxx sensors
Quickcam Express 046d:0840 and maybe others
Driver version: v 2.60 from 2.6.31-rc7
Initialize image size before it's used to initialize exposure.
Work around lack of exposure set hardware latch with a sequence of
register writes in a single I2C command packet.
Signed-off-by: James Blanford jhblanf...@gmail.com
--- a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-01
09:45:42.0 -0400
+++ b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
14:59:35.0 -0400
@@ -252,7 +252,7 @@ static int hdcs_set_exposure(struct gspc
within the column processing period */
int mnct;
int cycles, err;
- u8 exp[4];
+ u8 exp[14];
cycles = val * HDCS_CLK_FREQ_MHZ;
@@ -288,24 +288,37 @@ static int hdcs_set_exposure(struct gspc
srowexp = max_srowexp;
if (IS_1020(sd)) {
- exp[0] = rowexp 0xff;
- exp[1] = rowexp 8;
- exp[2] = (srowexp 2) 0xff;
- /* this clears exposure error flag */
- exp[3] = 0x1;
- err = hdcs_reg_write_seq(sd, HDCS_ROWEXPL, exp, 4);
+ exp[0] = HDCS20_CONTROL;
+ exp[1] = 0x00; /* Stop streaming */
+ exp[2] = HDCS_ROWEXPL;
+ exp[3] = rowexp 0xff;
+ exp[4] = HDCS_ROWEXPH;
+ exp[5] = rowexp 8;
+ exp[6] = HDCS20_SROWEXP;
+ exp[7] = (srowexp 2) 0xff;
+ exp[8] = HDCS20_ERROR;
+ exp[9] = 0x10; /* Clear exposure error flag*/
+ exp[10] = HDCS20_CONTROL;
+ exp[11] = 0x04; /* Restart streaming */
+ err = stv06xx_write_sensor_bytes(sd, exp, 6);
} else {
- exp[0] = rowexp 0xff;
- exp[1] = rowexp 8;
- exp[2] = srowexp 0xff;
- exp[3] = srowexp 8;
- err = hdcs_reg_write_seq(sd, HDCS_ROWEXPL, exp, 4);
+ exp[0] = HDCS00_CONTROL;
+ exp[1] = 0x00; /* Stop streaming */
+ exp[2] = HDCS_ROWEXPL;
+ exp[3] = rowexp 0xff;
+ exp[4] = HDCS_ROWEXPH;
+ exp[5] = rowexp 8;
+ exp[6] = HDCS00_SROWEXPL;
+ exp[7] = srowexp 0xff;
+ exp[8] = HDCS00_SROWEXPH;
+ exp[9] = srowexp 8;
+ exp[10] = HDCS_STATUS;
+ exp[11] = 0x10; /* Clear exposure error flag*/
+ exp[12] = HDCS00_CONTROL;
+ exp[13] = 0x04; /* Restart streaming */
+ err = stv06xx_write_sensor_bytes(sd, exp, 7);
if (err 0)
return err;
-
- /* clear exposure error flag */
- err = stv06xx_write_sensor(sd,
-HDCS_STATUS, BIT(4));
}
PDEBUG(D_V4L2, Writing exposure %d, rowexp %d, srowexp %d,
val, rowexp, srowexp);
@@ -577,11 +590,11 @@ static int hdcs_init(struct sd *sd)
if (err 0)
return err;
- err = hdcs_set_exposure(sd-gspca_dev, HDCS_DEFAULT_EXPOSURE);
+ err = hdcs_set_size(sd, hdcs-array.width, hdcs-array.height);
if (err 0)
return err;
- err = hdcs_set_size(sd, hdcs-array.width, hdcs-array.height);
+ err = hdcs_set_exposure(sd-gspca_dev, HDCS_DEFAULT_EXPOSURE);
return err;
}
--
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
LinuxTV firmware blocks all wireless connections / traffic
Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV. Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE 3.5.10, kernel 2.6.27-1-mepis-smp All three machines now have wireless blocked, either do not connect or all packets dropped/blocked if a connection is made. Used the resources from LinuxTV (dot) org to get it working, they are referenced and posted as follows: linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware *** ** Quote: In order to use the LinuxTV driver, you need to download and install the firmware for the xc5000. Quote: wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh sh extract (dot) sh cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware :Unquote Note: Though the usual directory location in which the firmware file is placed is /lib/firmware, this may differ in the case of some distros; consult your distro's documentation for the appropriate location. The firmware will be added lazily (on-demand) when you first use the driver. Drivers The xc5000 driver needed for this WinTV-HVR-950Q is already part of the latest Linux kernel (part of v4l-dvb drivers). Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. :Unquote *** ** *** ** So on Saturday I got this up and running... and Sunday morning recorded one show successfully that had set up on a timer. Then set up three consecutive shows for the afternoon. They were all part of a series on the same channel. Here are the results: * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. * Show C, supposed to be 2.0 hours long, result was 2.7gb file size, about the first hour is missing. At about this point, I lost wireless internet connectivity on TV recording laptop. Machine sees the access point, but won't connect. Went to my main desktop where i had first worked with this Hauppauge WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost internet, even though it was right next to AP and got a very good signal. Thought it was maybe the AP, so switched it out for a working spare. Same results. Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD and an 8.06 Live USB stick and hit the road to go to a reliable high speed wifi spot. Same results... changins ISPs resulted in the same issues. Also same ting happened with the spare laptop, an IBM T43 Thinkpad I had also done the wget ... steventoth (dot) net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip firmware thing to. Was able to get one machine, while running a LIVE USB session, to connect, but zero packets received.. ALL were blocked. The connection information said ALL packets were dropped. None of the two other machines connected to wireless on a LiveCD or LiveUSB thing too Three machines. All different brands (HP, Dell, and IBM) with different wifi cards. All three see the access point ESSID, but none connect. This does not *feel* good. What got flashed? Can this be resolved? Came home. No difference. Grabbed a laptop that i had NOT done the firmware thing to and that is what I am using to write this. Hooked right up to the AP. Please help... that is too much hardware disabled for me to think calmly. I'd really like to make the USB tv tuner work... what a great way to PVR / DVR, but I need wireless. Can provide any details requested to drive this towards a fix! Thank you, Clinton -- 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] stv06xx webcams with HDCS 1xxx sensors
Quickcam Express 046d:0840 and maybe others
Driver version: v 2.60 from 2.6.31-rc7
Due to rounding and clipping, exposure and gain settings do not map to
unique register values. Rather than read the registers and report gain
and exposure that may be different than the values that were set, just
cache the latest values that were set and report them. Reduce exposure
range from 0-65535 to 0-255 so libv4l's autogain doesn't take forever.
Remove vestiges of driver signal processing that is now handled by
libv4l.
Signed-off-by: James Blanford jhblanf...@gmail.com
diff -upr a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c
b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c
--- a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
14:59:35.0 -0400
+++ b/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.c 2009-09-09
16:30:08.0 -0400
@@ -37,7 +37,7 @@ static const struct ctrl hdcs1x00_ctrl[]
.type = V4L2_CTRL_TYPE_INTEGER,
.name = exposure,
.minimum= 0x00,
- .maximum= 0x,
+ .maximum= 0xff,
.step = 0x1,
.default_value = HDCS_DEFAULT_EXPOSURE,
.flags = V4L2_CTRL_FLAG_SLIDER
@@ -120,6 +120,7 @@ struct hdcs {
} exp;
int psmp;
+ u8 exp_cache, gain_cache;
};
static int hdcs_reg_write_seq(struct sd *sd, u8 reg, u8 *vals, u8 len)
@@ -205,34 +206,8 @@ static int hdcs_get_exposure(struct gspc
struct sd *sd = (struct sd *) gspca_dev;
struct hdcs *hdcs = sd-sensor_priv;
- /* Column time period */
- int ct;
- /* Column processing period */
- int cp;
- /* Row processing period */
- int rp;
- int cycles;
- int err;
- int rowexp;
- u16 data[2];
-
- err = stv06xx_read_sensor(sd, HDCS_ROWEXPL, data[0]);
- if (err 0)
- return err;
-
- err = stv06xx_read_sensor(sd, HDCS_ROWEXPH, data[1]);
- if (err 0)
- return err;
-
- rowexp = (data[1] 8) | data[0];
+ *val = hdcs-exp_cache;
- ct = hdcs-exp.cto + hdcs-psmp + (HDCS_ADC_START_SIG_DUR + 2);
- cp = hdcs-exp.cto + (hdcs-w * ct / 2);
- rp = hdcs-exp.rs + cp;
-
- cycles = rp * rowexp;
- *val = cycles / HDCS_CLK_FREQ_MHZ;
- PDEBUG(D_V4L2, Read exposure %d, *val);
return 0;
}
@@ -254,7 +229,10 @@ static int hdcs_set_exposure(struct gspc
int cycles, err;
u8 exp[14];
- cycles = val * HDCS_CLK_FREQ_MHZ;
+ val = 0xff;
+ hdcs-exp_cache = val;
+
+ cycles = val * HDCS_CLK_FREQ_MHZ * 257;
ct = hdcs-exp.cto + hdcs-psmp + (HDCS_ADC_START_SIG_DUR + 2);
cp = hdcs-exp.cto + (hdcs-w * ct / 2);
@@ -325,49 +303,42 @@ static int hdcs_set_exposure(struct gspc
return err;
}
-static int hdcs_set_gains(struct sd *sd, u8 r, u8 g, u8 b)
+static int hdcs_set_gains(struct sd *sd, u8 g)
{
+ struct hdcs *hdcs = sd-sensor_priv;
+ int err;
u8 gains[4];
+ hdcs-gain_cache = g;
+
/* the voltage gain Av = (1 + 19 * val / 127) * (1 + bit7) */
- if (r 127)
- r = 0x80 | (r / 2);
if (g 127)
g = 0x80 | (g / 2);
- if (b 127)
- b = 0x80 | (b / 2);
gains[0] = g;
- gains[1] = r;
- gains[2] = b;
+ gains[1] = g;
+ gains[2] = g;
gains[3] = g;
- return hdcs_reg_write_seq(sd, HDCS_ERECPGA, gains, 4);
+ err = hdcs_reg_write_seq(sd, HDCS_ERECPGA, gains, 4);
+ return err;
}
static int hdcs_get_gain(struct gspca_dev *gspca_dev, __s32 *val)
{
struct sd *sd = (struct sd *) gspca_dev;
- int err;
- u16 data;
+ struct hdcs *hdcs = sd-sensor_priv;
- err = stv06xx_read_sensor(sd, HDCS_ERECPGA, data);
+ *val = hdcs-gain_cache;
- /* Bit 7 doubles the gain */
- if (data 0x80)
- *val = (data 0x7f) * 2;
- else
- *val = data;
-
- PDEBUG(D_V4L2, Read gain %d, *val);
- return err;
+ return 0;
}
static int hdcs_set_gain(struct gspca_dev *gspca_dev, __s32 val)
{
PDEBUG(D_V4L2, Writing gain %d, val);
return hdcs_set_gains((struct sd *) gspca_dev,
- val 0xff, val 0xff, val 0xff);
+ val 0xff);
}
static int hdcs_set_size(struct sd *sd,
@@ -585,8 +556,7 @@ static int hdcs_init(struct sd *sd)
if (err 0)
return err;
- err = hdcs_set_gains(sd, HDCS_DEFAULT_GAIN, HDCS_DEFAULT_GAIN,
-HDCS_DEFAULT_GAIN);
+ err = hdcs_set_gains(sd, HDCS_DEFAULT_GAIN);
if (err 0)
return err;
diff -upr a/drivers/media/video/gspca/stv06xx/stv06xx_hdcs.h
Re: LinuxTV firmware blocks all wireless connections / traffic
On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyerclintonmeye...@gmail.com wrote: Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV. Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE 3.5.10, kernel 2.6.27-1-mepis-smp All three machines now have wireless blocked, either do not connect or all packets dropped/blocked if a connection is made. Used the resources from LinuxTV (dot) org to get it working, they are referenced and posted as follows: linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware *** ** Quote: In order to use the LinuxTV driver, you need to download and install the firmware for the xc5000. Quote: wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh sh extract (dot) sh cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware :Unquote Note: Though the usual directory location in which the firmware file is placed is /lib/firmware, this may differ in the case of some distros; consult your distro's documentation for the appropriate location. The firmware will be added lazily (on-demand) when you first use the driver. Drivers The xc5000 driver needed for this WinTV-HVR-950Q is already part of the latest Linux kernel (part of v4l-dvb drivers). Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. :Unquote *** ** *** ** So on Saturday I got this up and running... and Sunday morning recorded one show successfully that had set up on a timer. Then set up three consecutive shows for the afternoon. They were all part of a series on the same channel. Here are the results: * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. * Show C, supposed to be 2.0 hours long, result was 2.7gb file size, about the first hour is missing. At about this point, I lost wireless internet connectivity on TV recording laptop. Machine sees the access point, but won't connect. Went to my main desktop where i had first worked with this Hauppauge WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost internet, even though it was right next to AP and got a very good signal. Thought it was maybe the AP, so switched it out for a working spare. Same results. Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD and an 8.06 Live USB stick and hit the road to go to a reliable high speed wifi spot. Same results... changins ISPs resulted in the same issues. Also same ting happened with the spare laptop, an IBM T43 Thinkpad I had also done the wget ... steventoth (dot) net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip firmware thing to. Was able to get one machine, while running a LIVE USB session, to connect, but zero packets received.. ALL were blocked. The connection information said ALL packets were dropped. None of the two other machines connected to wireless on a LiveCD or LiveUSB thing too Three machines. All different brands (HP, Dell, and IBM) with different wifi cards. All three see the access point ESSID, but none connect. This does not *feel* good. What got flashed? Can this be resolved? Came home. No difference. Grabbed a laptop that i had NOT done the firmware thing to and that is what I am using to write this. Hooked right up to the AP. Please help... that is too much hardware disabled for me to think calmly. I'd really like to make the USB tv tuner work... what a great way to PVR / DVR, but I need wireless. Can provide any details requested to drive this towards a fix! Thank you, Clinton -- 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 Hello Clinton, That is indeed curious. It's hard to imagine how there could be interference between the V4L subsystem and the wireless subsystem, short of hitting some sort of timing condition on crappy wireless drivers. Here are a few questions: 1. You specified you followed the instructions for the firmware, but are you running the current v4l-dvb code, or are you just using whatever came with your Debian kernel? If you're actually using the 1.1 Xceive firmware, I'm assuming you're still using the old code. 2. How reproducible is this? Does it occur even if the device is connected but you do not attempt any capturing with the device? Does it always drop out while capturing? 3. What type of wireless cards are you using? Are they implemented over PCI, or USB? If the wireless cards are USB based, perhaps there is some sort of USB bandwidth issue. 4. Are you actively watching the programs you are capturing? Or are you just saving the content to disk? What application are you using to capture the ATSC video?
gspca stv06xx performance regression - request for testing
Howdy folks,
Now that I have my old quickcam express working, I can confirm that the
frame rate is half what it was with the old out-of-tree driver. The
gspca driver is throwing out every other frame. When a frame is
completed, a new frame is started with a new frame buffer that passes
the test for being properly queued. But after the first packet is
analysed by the subdriver, the exact same test fails and the entire
frame is marked for discard.
I'm not having any luck tracking the problem down. I would like to
find out if it's just my sensor, my subdriver or the entire gspca
family. I have some printks that can be added to gspca.c that easily
and quickly illustrate the problem.
--- gspca.c.orig2009-09-04 00:58:26.0 -0400
+++ gspca.c 2009-09-09 16:27:10.0 -0400
@@ -268,9 +268,11 @@
/* when start of a new frame, if the current frame buffer
* is not queued, discard the whole frame */
if (packet_type == FIRST_PACKET) {
+ printk(KERN_DEBUG New frame - first packet\n);
if ((frame-v4l2_buf.flags BUF_ALL_FLAGS)
!= V4L2_BUF_FLAG_QUEUED) {
gspca_dev-last_packet_type = DISCARD_PACKET;
+ printk(KERN_DEBUG Frame marked for discard\n);
return frame;
}
frame-data_end = frame-data;
@@ -306,6 +308,7 @@
wake_up_interruptible(gspca_dev-wq); /* event = new frame */
i = (gspca_dev-fr_i + 1) % gspca_dev-nframes;
gspca_dev-fr_i = i;
+ printk(KERN_DEBUG Frame completed\n);
PDEBUG(D_FRAM, frame complete len:%d q:%d i:%d o:%d,
frame-v4l2_buf.bytesused,
gspca_dev-fr_q,
@@ -396,6 +399,7 @@
}
gspca_dev-fr_i = gspca_dev-fr_o = gspca_dev-fr_q = 0;
gspca_dev-last_packet_type = DISCARD_PACKET;
+ printk(KERN_DEBUG Frame alloc\n);
gspca_dev-sequence = 0;
return 0;
}
When I test, I get:
Sep 8 10:27:48 blackbart kernel: Frame alloc
Sep 8 10:27:48 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame completed
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame marked for discard
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame completed
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame marked for discard
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame completed
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame marked for discard
Sep 8 10:27:49 blackbart kernel: New frame - first packet
Sep 8 10:27:49 blackbart kernel: Frame completed
Of course, I shouldn't be getting every other frame marked for
discard. Note that this marking takes place when the first packet
comes across, _before_ any image data is passed.
I'm hoping someone has a few minutes to make a little patch, run the
cam for a couple seconds and look at the debug log. Any comments are
welcome as well.
Thanks,
- Jim
--
There are two kinds of people. The innocent and the living.
--
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: gspca stv06xx performance regression - request for testing
On Wed, 9 Sep 2009 18:11:39 -0400 James Blanford jhblanf...@gmail.com wrote: Howdy folks, Now that I have my old quickcam express working, I can confirm that the frame rate is half what it was with the old out-of-tree driver. The gspca driver is throwing out every other frame. When a frame is completed, a new frame is started with a new frame buffer that passes the test for being properly queued. But after the first packet is analysed by the subdriver, the exact same test fails and the entire frame is marked for discard. I also have a QuickCam Express, the one with pb0100 sensor. It is slow indeed, but I can't really make a comparison with the old driver. I'm hoping someone has a few minutes to make a little patch, run the cam for a couple seconds and look at the debug log. Any comments are welcome as well. I get some discarded frames with stv06xx , but not as regularly as you. Also, no discarded frames with ov534 subdriver. Here's the log: [55231.009253] gspca: main v2.7.0 registered [55231.011569] STV06xx: Probing for a stv06xx device [55231.011575] gspca: probing 046d:0840 [55231.011582] STV06xx: Configuring camera [55231.024510] STV06xx: Photobit pb0100 sensor detected [55231.024517] STV06xx: Initializing camera [55231.310369] gspca: probe ok [55231.310408] usbcore: registered new interface driver STV06xx [55231.310413] STV06xx: registered [55445.692828] Frame alloc [55446.298735] New frame - first packet [55446.426667] Frame completed [55446.426674] New frame - first packet [55446.426677] Frame marked for discard [55446.554582] New frame - first packet [55446.714487] Frame completed [55446.714495] New frame - first packet [55446.874375] Frame completed [55446.874383] New frame - first packet [55447.034246] Frame completed [55447.034253] New frame - first packet [55447.194141] Frame completed [55447.194150] New frame - first packet [55447.354020] Frame completed [55447.354027] New frame - first packet [55447.354029] Frame marked for discard [55447.481948] New frame - first packet [55447.641846] Frame completed [55447.641853] New frame - first packet [55447.801725] Frame completed [55447.801732] New frame - first packet [55447.961596] Frame completed [55447.961603] New frame - first packet [55448.121467] Frame completed [55448.121474] New frame - first packet [55448.281355] Frame completed [55448.281363] New frame - first packet [55448.409305] Frame completed [55448.409313] New frame - first packet [55448.569191] Frame completed [55448.569199] New frame - first packet [55448.729067] Frame completed [55448.729075] New frame - first packet [55448.888939] Frame completed [55448.888946] New frame - first packet [55449.048822] Frame completed [55449.048830] New frame - first packet [55449.208710] Frame completed [55449.208717] New frame - first packet [55449.336668] Frame completed [55449.336675] New frame - first packet [55449.496532] Frame completed [55449.496540] New frame - first packet [55449.656421] Frame completed [55449.656429] New frame - first packet [55449.816286] Frame completed [55449.816294] New frame - first packet [55449.976166] Frame completed [55449.976173] New frame - first packet [55449.976175] Frame marked for discard [55450.136047] New frame - first packet -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpIkQ6aDnFzY.pgp Description: PGP signature
Re: saa7134 doesn't work after warm-reboot
On Wed, Sep 9, 2009 at 1:37 PM, David Whyte david.wh...@gmail.com wrote: My brother lives in an area that suffers very short power-outages if there is a storm or whatever and I have noticed that after such an event, he loses the ability to record TV from both tuners and generally only one will work. I am never sure if it is always the same tuner that as busted since I don't know which is dvb0 or dvb1 at any point in time. To correct this, I remote into the server and issue a 'halt', get him to unplug it from the wall then press the power button on the front of the machine, re-plug it into the wall and boot up the server. Then both tuners are working fine. Further info, the power outage was for about 10 seconds in the latest incident. Also, there is no need to unplug the PC power from the wall and press the power button etc to recover, you just need to leave the machine powered down for a short while. Sounds a lot like the issues I have read about where the firmware remains in the tuner card but is corrupt or something. The only way is to clear the firmware and re-upload it, generally by powering down for sometime but I am hoping that you can do this by unloading then loading the modules. Is this possible? Anyone know which modules in this instance? Regards, Whytey -- 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: tuner, code for discuss
Hi All
This is my next patch.
Changes:
1. By default charge pump is ON
2. For radio mode charge pump set to OFF
3. Set correct AGC value in radio mode
4. Add control gain of AGC.
5. New function simple_get_tv_gain and simple_set_tv_gain for read/write gain
of AGC.
6. Add some code for control gain from saa7134 part. By default this control is
OFF 7. When TV card can
manipulate this control, enable it.
Main changes is control value of AGC TOP in .initdata = tua603x_agc112 array.
Use this value for set AGC TOP after set freq of TV.
I don't understand how to correct call new function for read/write value of AGC
TOP.
What you think about it??
diff -r 3f7e382dfae5 linux/drivers/media/common/tuners/tuner-simple.c
--- a/linux/drivers/media/common/tuners/tuner-simple.c Sun Aug 16 21:53:17
2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-simple.c Thu Sep 10 06:05:49
2009 +1000
@@ -144,6 +144,7 @@
case TUNER_PHILIPS_FM1256_IH3:
case TUNER_LG_NTSC_TAPE:
case TUNER_TCL_MF02GIP_5N:
+ case TUNER_TCL_MFPE05_2:
return ((status TUNER_SIGNAL) == TUNER_STEREO_MK3);
default:
return status TUNER_STEREO;
@@ -491,6 +492,18 @@
(should be 4)\n, rc);
break;
}
+ case TUNER_TCL_MFPE05_2:
+ {
+
+ printk(posttune TCL_MFPE05_2\r\n);
+
+ if (priv-tun-initdata) {
+ printk(write AUX byte = 0x%X,priv-tun-initdata[2]);
+ simple_set_aux_byte(fe, config, priv-tun-initdata[2]);
+ }
+
+ break;
+ }
}
return 0;
@@ -499,6 +512,7 @@
static int simple_radio_bandswitch(struct dvb_frontend *fe, u8 *buffer)
{
struct tuner_simple_priv *priv = fe-tuner_priv;
+ u8 rc;
switch (priv-type) {
case TUNER_TENA_9533_DI:
@@ -513,6 +527,11 @@
case TUNER_LG_NTSC_TAPE:
case TUNER_PHILIPS_FM1256_IH3:
case TUNER_TCL_MF02GIP_5N:
+ buffer[3] = 0x19;
+ break;
+ case TUNER_TCL_MFPE05_2:
+ rc = buffer[2]0xbf;
+ buffer[2] = rc; /* Switch OFF Charge Pump */
buffer[3] = 0x19;
break;
case TUNER_TNF_5335MF:
@@ -754,7 +773,53 @@
if (4 != rc)
tuner_warn(i2c i/o error: rc == %d (should be 4)\n, rc);
+ /* Write AUX byte */
+ switch (priv-type) {
+ case TUNER_TCL_MFPE05_2:
+ printk(write AUX byte\n);
+ simple_set_aux_byte(fe, 0x98, 0x20);
+ break;
+ }
+
return 0;
+}
+
+static int simple_set_tv_gain(struct dvb_frontend *fe,
+ u8 tvgain)
+{
+ struct tuner_simple_priv *priv = fe-tuner_priv;
+ int ret = -EINVAL;
+
+ switch (priv-type) {
+ case TUNER_TCL_MFPE05_2:
+ if (priv-tun-initdata) {
+ priv-tun-initdata[2] = tvgain;
+ printk(set AUX byte = 0x%X,priv-tun-initdata[2]);
+ ret = 0;
+ }
+ break;
+ } /* switch (priv-type) */
+
+ return ret;
+}
+
+static int simple_get_tv_gain(struct dvb_frontend *fe,
+ u8 *tvgain)
+{
+ struct tuner_simple_priv *priv = fe-tuner_priv;
+ int ret = -EINVAL;
+
+ switch (priv-type) {
+ case TUNER_TCL_MFPE05_2:
+ if (priv-tun-initdata) {
+ *tvgain = priv-tun-initdata[2];
+ printk(read AUX byte = 0x%X,priv-tun-initdata[2]);
+ ret = 0;
+ }
+ break;
+ } /* switch (priv-type) */
+
+ return ret;
}
static int simple_set_params(struct dvb_frontend *fe,
diff -r 3f7e382dfae5 linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Sun Aug 16 21:53:17
2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-types.c Thu Sep 10 06:05:49
2009 +1000
@@ -1321,6 +1321,31 @@
},
};
+/* TUNER_TCL_MFPE05_2 - TCL MFPE05-2 ALL */
+
+static struct tuner_range tuner_tcl_mfpe05_2_all_ranges[] = {
+ { 16 * 158.00 /*MHz*/, 0xc6, 0x01, },
+ { 16 * 441.00 /*MHz*/, 0xc6, 0x02, },
+ { 16 * 864.00, 0xc6, 0x04, },
+};
+
+static struct tuner_params tuner_tcl_mfpe05_2_all_params[] = {
+ {
+ .type = TUNER_PARAM_TYPE_PAL,
+ .ranges = tuner_tcl_mfpe05_2_all_ranges,
+ .count = ARRAY_SIZE(tuner_tcl_mfpe05_2_all_ranges),
+ .cb_first_if_lower_freq = 1,
+ .has_tda9887 = 1,
+ .port1_active = 1,
+ .port2_active = 1,
+ .port2_invert_for_secam_lc = 1,
+ .port1_fm_high_sensitivity = 1,
+ .default_top_mid = -2,
+ .default_top_secam_mid = -2,
+
