Re: Videotext application crashes the kernel due to DVB-demux patch
Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT sid:pmtpid:ttpid:type:provider:name:language:texttype:magazine:page 28006:100:130:1:ZDFvision:ZDF:lang=deu:type=1:magazine=1:page= 0 28011:600:630:1:ZDFvision:ZDFinfokanal:lang=deu:type=1:magazine=1:page= 0 28014:650:630:1:ZDFvision:zdf_neo:lang=deu:type=1:magazine=1:page= 0 28016:1100:630:1:ZDFvision:ZDFtheaterkanal:lang=deu:type=1:magazine=1:page= 0 28007:200:230:1:ZDFvision:3sat:lang=deu:type=1:magazine=1:page= 0 28008:300:330:1:ZDFvision:KiKa:lang=deu:type=1:magazine=1:page= 0 28017:411:8191:2:ZDFvision:DRadio Wissen:lang=:type=0:magazine=0:page= 0 28012:700:8191:2:ZDFvision:DKULTUR:lang=:type=0:magazine=0:page= 0 28013:800:8191:2:ZDFvision:DLF:lang=:type=0:magazine=0:page= 0 Using: Service ID = 28006 ; PMT PID = 100 ; TXT PID = 130 ; Service type = 1 ; Provider Name = ZDFvision ; Service name = ZDF ; language = deu ; Text type = 1 ; Text Magazine = 1 ; Text page = 0 alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563492] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb1/1-0:1.0/uevent Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563589] Process alevt (pid: 1780, ti=e7934000 task=e7915be0 task.ti=e7934000) Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563592] Stack: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563622] Call Trace: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8 e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b 46 04 8d 48 f8 8b 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89 50 04 89 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563697] EIP: [f8cec1b2] dvb_demux_release+0x43/0x183 [dvb_core] SS:ESP 0068:e7935f58 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563706] CR2: I don't have a 32 bti machine set up to compile the module and compare the disassembly directly. However, the kernel code above disassembles to this, and is supposedly in dvb_demux_release() but things have been inlined by the compiler: 1c: 8d 56 78lea0x78(%esi),%edx 1f: 89 54 24 04 mov%edx,0x4(%esp) 23: 89 d0 mov%edx,%eax 25: e8 e4 da 4c c8 call 0xc84cdb0e 2a: 89 f0 mov%esi,%eax 2c: e8 31 ff ff ff call 0xff62 (dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here %esi holds dmxdevfilter) 31: 83 7e 4c 01 cmpl $0x1,0x4c(%esi)if (dmxdevfilter-state DMXDEV_STATE_SET) 35: 76 73 jbe0xaa return 0; 37: 83 7e 48 02 cmpl $0x2,0x48(%esi)if (dmxdevfilter-type == DMXDEV_TYPE_PES) 3b: 75 49 jne0x86 (dvb_dmxdev_delete_pids() appears to be inlined starting here %esi still holds dmxdevfilter) 3d: 8b 46 04mov0x4(%esi),%eax %eax gets loaded with dmxdevfilter-feed.ts for list_for_each_entry_safe(feed, tmp, dmxdevfilter-feed.ts, ... 40: 8d 48 f8lea-0x8(%eax),%ecx%ecx is feed and gets loaded with the next struct dmxdev_feed pointed to by the dmxdevfilter-feed.ts list 43: 8b 41 08mov0x8(%ecx),%eax Oops appears to happen here: %ecx and hence feed was (craftily?) set to 0xfff8 based on CR2 above 46: 8d 58 f8lea-0x8(%eax),%ebx 49: 8d 7e 04lea0x4(%esi),%edi 4c: eb 28 jmp0x76 4e: 8b 41 08mov
Re: [PATCH ] libv4l: skip false Pixart markers
Hi,
On 02/01/2010 11:13 PM, Németh Márton wrote:
From: Márton Némethnm...@freemail.hu
The byte sequence 0xff, 0xff, 0xff 0xff is not a real marker to skip, instead
it is one byte from the image and the following three 0xff bytes might belong
to a real marker. Modify pixart_fill_nbits() macro to pass the first 0xff byte
as an image data.
Oh, good catch. I'm still seeing the occasional bad frame though :(
While on the subject of the pac7302. I've been playing around a bit, and I have
the
feeling that if we were to go for a lower auto gain target (set autogain off and
lower exposure, you can do this ie with v4l2ucp), combined with a gamma
correction of
1500 (again use ie v4l2ucp), the images is much better (less over exposed, more
contrast).
Do you agree ?
Regards,
Hans
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r f23c5a878fb1 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 13:32:46 2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 23:05:39 2010 +0100
@@ -339,10 +339,15 @@
} \
break; \
case 0xff: \
- if (stream[1] == 0xff (stream[2] 7 || stream[2] == 0xff)) { \
- stream += 3; \
- c = *stream++; \
- break; \
+ if (stream[1] == 0xff) { \
+ if (stream[2] 7) { \
+ stream += 3; \
+ c = *stream++; \
+ break; \
+ } else if (stream[2] == 0xff) { \
+ /* four 0xff in a row: the first belongs to the image data
*/ \
+ break; \
+ }\
} \
/* Error fall through */ \
default: \
--
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: libv4l: possible problem found in PAC7302 JPEG decoding
On 02/01/2010 10:23 PM, Németh Márton wrote: Hello Hans, while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the following behaviour. The stream received from the webcam is splitted by the gspca_pac7302 subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()). Before transmitting the data to the userspace a JPEG header is added (pac_start_frame()) and the footer after the bytes 0xff, 0xd9 are removed. The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact): 1. JPEG header 2. Some bytes of image data (near to 1024 bytes) 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data. This marker sequence and data repeats a couple of time. Exactly how much depends on the image content. 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data. This marker sequence and data also repeats a couple of time. 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of image data bytes. 6. The End of Image (EOI) marker 0xff, 0xd9. Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff, 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then the three 0xff bytes from the marker is also removed. The xx (which really belongs to the marker) is left in the image data instead of the original 0xff byte. Based on my experiments this problem sometimes causes corrupted image decoding or that the JPEG image cannot be decoded at all. Hello Németh I remember the problem as I was working on the PAC7311. http://www.kaiser-linux.li/index.php?title=PAC7311 This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 0xnn markers. See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz decoder/gspcadecoder.c pac7311_decode() Thomas -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Jean Delvare wrote: Hi Hermann, On Tue, 02 Feb 2010 02:47:53 +0100, hermann pitton wrote: Hi Jean, Am Montag, den 01.02.2010, 10:56 +0100 schrieb Jean Delvare: Hi Hermann, On Mon, 01 Feb 2010 02:16:35 +0100, hermann pitton wrote: For now, I only faked a P7131 Dual with a broken IR receiver on a 2.6.29 with recent, you can see that gpio 0x4 doesn't go high, but your patch should enable the remote on that P7131 analog only. I'm not sure why you had to fake anything? What I'd like to know is simply if my first patch had any negative effect on other cards. because I simply don't have that Asus My Cinema analog only in question. To recap, you previously announced a patch, tested by Daro, claiming to get the remote up under auto detection for that device and I told you having some doubts on it. My first patch was not actually tested by Daro. What he tested was loading the driver with card=146. At first I thought it was equivalent, but since then I have realized it wasn't. That's the reason why the Tested-by: was turned into a mere Cc: on my second and third patches. Mauro prefers to have a fix for that single card in need for now. Since nobody else cares, For now, see above, I can confirm that your last patch for that single device should work to get IR up with auto detection in delay after we change the card such late with eeprom detection. The meaning of that byte in use here is unknown to me, we should avoid such as much we can! It can turn out to be only some pseudo service. If your call for testers on your previous attempt, really reaches some for some reason, I'm with you, but for now I have to keep the car operable within all such snow. That I understand. What I don't understand is: if you have a SAA7134-based card, why don't you test my second patch (the one moving the call to saa7134_input_init1 to saa7134_hwinit2) on it, without faking anything? This would be a first, useful data point. The init1 code has 107 boards listed: SAA7134_BOARD_10MOONSTVMASTER3 SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331 SAA7134_BOARD_ASUST SAA7134_BOARD_AVACSSMARTTV SAA7134_BOARD_AVERMEDIA_305 SAA7134_BOARD_AVERMEDIA_307 SAA7134_BOARD_AVERMEDIA_777 SAA7134_BOARD_AVERMEDIA_A169_B SAA7134_BOARD_AVERMEDIA_A16AR SAA7134_BOARD_AVERMEDIA_A16D SAA7134_BOARD_AVERMEDIA_A700_HYBRID SAA7134_BOARD_AVERMEDIA_A700_PRO SAA7134_BOARD_AVERMEDIA_CARDBUS SAA7134_BOARD_AVERMEDIA_CARDBUS_501 SAA7134_BOARD_AVERMEDIA_CARDBUS_506 SAA7134_BOARD_AVERMEDIA_GO_007_FM SAA7134_BOARD_AVERMEDIA_GO_007_FM_PLUS SAA7134_BOARD_AVERMEDIA_M102 SAA7134_BOARD_AVERMEDIA_M103 SAA7134_BOARD_AVERMEDIA_M115 SAA7134_BOARD_AVERMEDIA_M135A SAA7134_BOARD_AVERMEDIA_STUDIO_305 SAA7134_BOARD_AVERMEDIA_STUDIO_307 SAA7134_BOARD_AVERMEDIA_STUDIO_505 SAA7134_BOARD_AVERMEDIA_STUDIO_507 SAA7134_BOARD_BEHOLD_401 SAA7134_BOARD_BEHOLD_403 SAA7134_BOARD_BEHOLD_403FM SAA7134_BOARD_BEHOLD_405 SAA7134_BOARD_BEHOLD_405FM SAA7134_BOARD_BEHOLD_407 SAA7134_BOARD_BEHOLD_407FM SAA7134_BOARD_BEHOLD_409 SAA7134_BOARD_BEHOLD_409FM SAA7134_BOARD_BEHOLD_505FM SAA7134_BOARD_BEHOLD_505RDS_MK3 SAA7134_BOARD_BEHOLD_505RDS_MK5 SAA7134_BOARD_BEHOLD_507_9FM SAA7134_BOARD_BEHOLD_507RDS_MK3 SAA7134_BOARD_BEHOLD_507RDS_MK5 SAA7134_BOARD_BEHOLD_607FM_MK3 SAA7134_BOARD_BEHOLD_607FM_MK5 SAA7134_BOARD_BEHOLD_607RDS_MK3 SAA7134_BOARD_BEHOLD_607RDS_MK5 SAA7134_BOARD_BEHOLD_609FM_MK3 SAA7134_BOARD_BEHOLD_609FM_MK5 SAA7134_BOARD_BEHOLD_609RDS_MK3 SAA7134_BOARD_BEHOLD_609RDS_MK5 SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM SAA7134_BOARD_BEHOLD_H6 SAA7134_BOARD_BEHOLD_M6 SAA7134_BOARD_BEHOLD_M63 SAA7134_BOARD_BEHOLD_M6_EXTRA SAA7134_BOARD_BEHOLD_X7 SAA7134_BOARD_CINERGY400 SAA7134_BOARD_CINERGY400_CARDBUS SAA7134_BOARD_CINERGY600 SAA7134_BOARD_CINERGY600_MK3 SAA7134_BOARD_ECS_TVP3XP SAA7134_BOARD_ECS_TVP3XP_4CB5 SAA7134_BOARD_ECS_TVP3XP_4CB6 SAA7134_BOARD_ENCORE_ENLTV SAA7134_BOARD_ENCORE_ENLTV_FM SAA7134_BOARD_ENCORE_ENLTV_FM53 SAA7134_BOARD_FLYDVBS_LR300 SAA7134_BOARD_FLYDVBTDUO SAA7134_BOARD_FLYDVBT_DUO_CARDBUS SAA7134_BOARD_FLYDVBT_HYBRID_CARDBUS SAA7134_BOARD_FLYDVBT_LR301 SAA7134_BOARD_FLYTVPLATINUM_FM SAA7134_BOARD_FLYTVPLATINUM_MINI2 SAA7134_BOARD_FLYVIDEO2000 SAA7134_BOARD_FLYVIDEO3000 SAA7134_BOARD_FLYVIDEO3000_NTSC SAA7134_BOARD_GENIUS_TVGO_A11MCE SAA7134_BOARD_GOTVIEW_7135 SAA7134_BOARD_HAUPPAUGE_HVR1110 SAA7134_BOARD_HAUPPAUGE_HVR1120 SAA7134_BOARD_HAUPPAUGE_HVR1150 SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG SAA7134_BOARD_KWORLD_TERMINATOR SAA7134_BOARD_KWORLD_VSTREAM_XPERT SAA7134_BOARD_KWORLD_XPERT SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S SAA7134_BOARD_MANLI_MTV001 SAA7134_BOARD_MANLI_MTV002 SAA7134_BOARD_MD2819 SAA7134_BOARD_MD5044 SAA7134_BOARD_MONSTERTV_MOBILE SAA7134_BOARD_MSI_TVATANYWHERE_PLUS SAA7134_BOARD_PINNACLE_300I_DVBT_PAL SAA7134_BOARD_PINNACLE_PCTV_110 SAA7134_BOARD_PINNACLE_PCTV_310 SAA7134_BOARD_PROTEUS_2309 SAA7134_BOARD_REAL_ANGEL_220 SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM SAA7134_BOARD_RTD_VFG7350 SAA7134_BOARD_SABRENT_SBTTVFM
Re: Lost remote after kernel/v4l update cx23885 chipset
On Mon, 2010-02-01 at 12:03 -0700, Timothy D. Lenz wrote: On 1/24/2010 1:07 PM, Timothy D. Lenz wrote: After updating from kernel 2.6.26.8 to 2.6.32.2 and from v4l of 05/19/2009 to 01/18/2010 I lost remote function with Dvico FusionHDTV7 Dual Express. The driver is loading, but not creating an IR device. Went over it with awalls on IRC. The log is at: http://pastebin.com/m4b02ff0c I noticed that in the kern.log there where 2 different ways ir-kbd-i2c showed up. ir-kbd-i2c no longer shows up when loading drivers. Jan 17 14:59:32 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 17 14:59:32 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] -- Jan 18 17:23:27 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 18 17:23:27 LLLx64-32 kernel: Creating IR device irrcv0 Jan 18 17:23:27 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-1/1-006b/ir0 [cx23885[0]] Jan 18 18:28:50 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 18 18:28:50 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] -- A driver load that worked: Jan 17 11:22:35 LLLx64-32 kernel: Linux video capture interface: v2.00 Jan 17 11:22:35 LLLx64-32 kernel: cx23885 driver version 0.0.2 loaded Jan 17 11:22:35 LLLx64-32 kernel: ACPI: PCI Interrupt :02:00.0[A] - Link [APC7] - GSI 16 (level, low) - IRQ 16 Jan 17 11:22:35 LLLx64-32 kernel: CORE cx23885[0]: subsystem: 18ac:d618, board: DViCO FusionHDTV7 Dual Express [card=10,autodetected] Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 17 11:22:35 LLLx64-32 kernel: xc5000 2-0064: creating new instance Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Firmware has not been loaded previously Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering new adapter (cx23885[0]) Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 17 11:22:35 LLLx64-32 kernel: xc5000 3-0064: creating new instance Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Firmware has not been loaded previously Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering new adapter (cx23885[0]) Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering adapter 1 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dev_checkrevision() Hardware revision = 0xb0 Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfdc0 Jan 17 11:22:35 LLLx64-32 kernel: PCI: Setting latency timer of device :02:00.0 to 64 Jan 17 11:22:35 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input8 Jan 17 11:22:35 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] Jan 17 11:22:36 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 17 11:22:36 LLLx64-32 kernel: firmware: requesting dvb-fe-xc5000-1.6.114.fw Jan 17 11:22:36 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 17 11:22:36 LLLx64-32 kernel: xc5000: firmware uploading... Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware upload complete... Jan 17 11:22:37 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 17 11:22:37 LLLx64-32 kernel: firmware: requesting dvb-fe-xc5000-1.6.114.fw Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware uploading... Jan 17 11:22:39 LLLx64-32 kernel: xc5000: firmware upload complete... -- And what it does now: Jan 23 17:10:47 LLLx64-32 kernel: Linux video capture interface: v2.00 Jan 23 17:10:47 LLLx64-32 kernel: cx23885 driver version 0.0.2 loaded Jan 23 17:10:47 LLLx64-32 kernel: cx23885 :02:00.0: PCI INT A - Link[APC7] - GSI 16 (level, low) - IRQ 16 Jan 23 17:10:47 LLLx64-32 kernel: CORE cx23885[0]: subsystem: 18ac:d618, board: DViCO FusionHDTV7 Dual Express [card=10,autodetected] Jan 23 17:10:47 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 23 17:10:47 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 23 17:10:47 LLLx64-32 kernel: xc5000 1-0064: creating new instance Jan 23 17:10:47 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 23 17:10:47 LLLx64-32
[PATCH] dvb: return -ENOMEM if kzalloc failed in dvb_usb_device_init()
If in a cold state and the download succeeded ret is zero, but we
should return -ENOMEM.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or shouldn't we?
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-init.c
b/drivers/media/dvb/dvb-usb/dvb-usb-init.c
index e331db8..5d91f70 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-init.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-init.c
@@ -243,7 +243,7 @@ int dvb_usb_device_init(struct usb_interface *intf,
d = kzalloc(sizeof(struct dvb_usb_device),GFP_KERNEL);
if (d == NULL) {
err(no memory for 'struct dvb_usb_device');
- return ret;
+ return -ENOMEM;
}
d-udev = udev;
--
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] cx23885: fix support for TBS 6920 card
Hi Steven, Steven Toth wrote: On 8/19/09 7:20 PM, Konstantin Dimitrov wrote: fix: GPIO initialization for TBS 6920 fix: wrong I2C address for demod on TBS 6920 fix: wrong I2C bus number for demod on TBS 6920 fix: wrong gen_ctrl_val value for TS1 port on TBS 6920 (and some other cards) add: module_param lnb_pwr_ctrl as option to choose between type 0 and type 1 of LNB power control (two TBS 6920 boards no matter that they are marked as the same hardware revision may have different types of LNB power control) fix: LNB power control function for type 0 doesn't preserve the previous GPIO state, which is critical add: LNB power control function for type 1 Signed-off-by: Bob Liub...@turbosight.com Signed-off-by: Konstantin Dimitrovkosio.dimit...@gmail.com I got a weird HTML related email bounce from vger when I responded originally to this via gmail. Maybe this time via thunderbird will bring success. ... Hmm. A custom hanging off of a gpio to something that looks like an i2c power control device. I want to review some of these generic (and no-so-generic) changes before we merge this patch. Is the datasheet for the LNB power control device available to the public? I'd like to understand some of the register details. What's the status of the current patch? It was submitted back on Aug, 2009, and marked as under review since then. Btw, the patch is currently broken, probably due to the changes on cx23885 driver during this period of time. patching file drivers/media/video/cx23885/cx23885-cards.c Hunk #1 FAILED at 704. Hunk #2 succeeded at 1020 with fuzz 2 (offset 133 lines). 1 out of 2 hunks FAILED -- saving rejects to file drivers/media/video/cx23885/cx23885-cards.c.rej patching file drivers/media/video/cx23885/cx23885-dvb.c Hunk #1 FAILED at 55. Hunk #2 succeeded at 75 (offset 3 lines). Hunk #3 FAILED at 427. Hunk #4 FAILED at 785. Hunk #5 FAILED at 805. 4 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx23885/cx23885-dvb.c.rej patching file drivers/media/video/cx23885/Makefile Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/cx23885/Makefile.rej patching file drivers/media/video/cx23885/tbs_lnb_pwr.c patching file drivers/media/video/cx23885/tbs_lnb_pwr.h Patch doesn't apply --- Subject: cx23885: fix support for TBS 6920 card Date: Wed, 19 Aug 2009 23:20:02 - From: Konstantin Dimitrov kosio.dimit...@gmail.com X-Patchwork-Id: 42777 fix: GPIO initialization for TBS 6920 fix: wrong I2C address for demod on TBS 6920 fix: wrong I2C bus number for demod on TBS 6920 fix: wrong gen_ctrl_val value for TS1 port on TBS 6920 (and some other cards) add: module_param lnb_pwr_ctrl as option to choose between type 0 and type 1 of LNB power control (two TBS 6920 boards no matter that they are marked as the same hardware revision may have different types of LNB power control) fix: LNB power control function for type 0 doesn't preserve the previous GPIO state, which is critical add: LNB power control function for type 1 Signed-off-by: Bob Liu b...@turbosight.com Signed-off-by: Konstantin Dimitrov kosio.dimit...@gmail.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 --- a/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19 14:11:49.0 +0300 +++ a/drivers/media/video/cx23885/cx23885-cards.c 2009-08-19 14:30:10.0 +0300 @@ -704,7 +704,14 @@ void cx23885_gpio_setup(struct cx23885_d case CX23885_BOARD_TEVII_S470: cx_write(MC417_CTL, 0x0036); cx_write(MC417_OEN, 0x1000); - cx_write(MC417_RWD, 0x1800); + + cx_set(MC417_RWD, 0x0002); + mdelay(200); + + cx_clear(MC417_RWD, 0x0800); + mdelay(200); + cx_set(MC417_RWD, 0x0800); + mdelay(200); break; case CX23885_BOARD_NETUP_DUAL_DVBS2_CI: /* GPIO-0 INTA from CiMax1 @@ -880,7 +887,7 @@ void cx23885_card_setup(struct cx23885_d case CX23885_BOARD_TEVII_S470: case CX23885_BOARD_TBS_6920: case CX23885_BOARD_DVBWORLD_2005: - ts1-gen_ctrl_val = 0x5; /* Parallel */ + ts1-gen_ctrl_val = 0x4; /* Parallel */ ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */ ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO; break; --- a/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19 14:11:49.0 +0300 +++ a/drivers/media/video/cx23885/cx23885-dvb.c 2009-08-19 15:25:57.0 +0300 @@ -55,6 +55,7 @@ #include netup-eeprom.h #include netup-init.h #include lgdt3305.h +#include tbs_lnb_pwr.h static unsigned int debug; @@ -71,6 +72,10 @@ MODULE_PARM_DESC(alt_tuner, Enable alte
Re: [PATCH 3/8] drivers/media/video/hdpvr: introduce missing kfree
Hi Janne, Janne Grunau wrote: On Fri, Sep 11, 2009 at 06:21:35PM +0200, Julia Lawall wrote: Error handling code following a kzalloc should free the allocated data. Thanks for the report. I'll commit a different patch which adds the buffer to the buffer list as soon it is allocated. The hdpvr_free_buffers() in the error handling code will clean it up then. See below: Any news about this subject? The current upstream code still misses the change bellow diff --git a/linux/drivers/media/video/hdpvr/hdpvr-video.c b/linux/drivers/media/video/hdpvr/hdpvr-video.c --- a/linux/drivers/media/video/hdpvr/hdpvr-video.c +++ b/linux/drivers/media/video/hdpvr/hdpvr-video.c @@ -134,6 +134,8 @@ v4l2_err(dev-v4l2_dev, cannot allocate buffer\n); goto exit; } + list_add_tail(buf-buff_list, dev-free_buff_list); + buf-dev = dev; urb = usb_alloc_urb(0, GFP_KERNEL); @@ -158,7 +160,6 @@ hdpvr_read_bulk_callback, buf); buf-status = BUFSTAT_AVAILABLE; - list_add_tail(buf-buff_list, dev-free_buff_list); } return 0; exit: -- 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 -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DM1105: could not attach frontend 195d:1105
Hi Igor,
What do you think ? if I can help you solve this, let me know what I
can do.
Thanks
Nameer
Nameer Kazzaz wrote:
Hi there,
dmesg output with patched dm1105.c against current v4l-dvb 'modprob
dm1105 card=4'
dm1105 :05:0f.0: PCI INT A - GSI 16 (level, low) - IRQ 16
DVB: registering new adapter (dm1105)
dm1105 :05:0f.0: MAC dd49b0dc
dm1105 :05:0f.0: could not attach frontend
dm1105 :05:0f.0: PCI INT A disabled
Thanks
Nameer Kazzaz
Igor M. Liplianin wrote:
On 20 ?? 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x // later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 // later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to
code
like that at the bottom. It still doesn't work, but feels a lot
closer.
Before I keep playing with values, I want to check I'm on the right
track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I
put the
logic into fe_attach because there was already card-specific logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input
= 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or
0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK, dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET ,
dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage function.
Try attached patch against current v4l-dvb tree with modprobe option
card=4
modprobe dm1105 card=4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L/DVB: lgs8gxx: remove firmware for lgs8g75
Mauro Carvalho Chehab wrote:
Ben Hutchings wrote:
The recently added support for lgs8g75 included some 8051 machine code
without accompanying source code. Replace this with use of the
firmware loader.
Compile-tested only.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
This firmware can be added to linux-firmware.git instead, and I will be
requesting that very shortly.
Had you submitted a patch for it already? Could you please test the patch
before we commit it at the tree?
Ping.
Ben.
drivers/media/dvb/frontends/Kconfig |1 +
drivers/media/dvb/frontends/lgs8gxx.c | 50
++--
2 files changed, 11 insertions(+), 40 deletions(-)
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index d7c4837..26b00ab 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -553,6 +553,7 @@ config DVB_LGS8GL5
config DVB_LGS8GXX
tristate Legend Silicon LGS8913/LGS8GL5/LGS8GXX DMB-TH demodulator
depends on DVB_CORE I2C
+select FW_LOADER
default m if DVB_FE_CUSTOMISE
help
A DMB-TH tuner module. Say Y when you want to support this frontend.
diff --git a/drivers/media/dvb/frontends/lgs8gxx.c
b/drivers/media/dvb/frontends/lgs8gxx.c
index eabcadc..1bfcf85 100644
--- a/drivers/media/dvb/frontends/lgs8gxx.c
+++ b/drivers/media/dvb/frontends/lgs8gxx.c
@@ -24,6 +24,7 @@
*/
#include asm/div64.h
+#include linux/firmware.h
#include dvb_frontend.h
@@ -46,42 +47,6 @@ module_param(fake_signal_str, int, 0644);
MODULE_PARM_DESC(fake_signal_str, fake signal strength for LGS8913.
Signal strength calculation is slow.(default:on).);
-static const u8 lgs8g75_initdat[] = {
-0x01, 0x30, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
-0xE4, 0xF5, 0xA8, 0xF5, 0xB8, 0xF5, 0x88, 0xF5,
-0x89, 0xF5, 0x87, 0x75, 0xD0, 0x00, 0x11, 0x50,
-0x11, 0x50, 0xF4, 0xF5, 0x80, 0xF5, 0x90, 0xF5,
-0xA0, 0xF5, 0xB0, 0x75, 0x81, 0x30, 0x80, 0x01,
-0x32, 0x90, 0x80, 0x12, 0x74, 0xFF, 0xF0, 0x90,
-0x80, 0x13, 0x74, 0x1F, 0xF0, 0x90, 0x80, 0x23,
-0x74, 0x01, 0xF0, 0x90, 0x80, 0x22, 0xF0, 0x90,
-0x00, 0x48, 0x74, 0x00, 0xF0, 0x90, 0x80, 0x4D,
-0x74, 0x05, 0xF0, 0x90, 0x80, 0x09, 0xE0, 0x60,
-0x21, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x1B, 0x12,
-0x00, 0xDD, 0x14, 0x60, 0x15, 0x12, 0x00, 0xDD,
-0x14, 0x60, 0x0F, 0x12, 0x00, 0xDD, 0x14, 0x60,
-0x09, 0x12, 0x00, 0xDD, 0x14, 0x60, 0x03, 0x12,
-0x00, 0xDD, 0x90, 0x80, 0x42, 0xE0, 0x60, 0x0B,
-0x14, 0x60, 0x0C, 0x14, 0x60, 0x0D, 0x14, 0x60,
-0x0E, 0x01, 0xB3, 0x74, 0x04, 0x01, 0xB9, 0x74,
-0x05, 0x01, 0xB9, 0x74, 0x07, 0x01, 0xB9, 0x74,
-0x0A, 0xC0, 0xE0, 0x74, 0xC8, 0x12, 0x00, 0xE2,
-0xD0, 0xE0, 0x14, 0x70, 0xF4, 0x90, 0x80, 0x09,
-0xE0, 0x70, 0xAE, 0x12, 0x00, 0xF6, 0x12, 0x00,
-0xFE, 0x90, 0x00, 0x48, 0xE0, 0x04, 0xF0, 0x90,
-0x80, 0x4E, 0xF0, 0x01, 0x73, 0x90, 0x80, 0x08,
-0xF0, 0x22, 0xF8, 0x7A, 0x0C, 0x79, 0xFD, 0x00,
-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD9,
-0xF6, 0xDA, 0xF2, 0xD8, 0xEE, 0x22, 0x90, 0x80,
-0x65, 0xE0, 0x54, 0xFD, 0xF0, 0x22, 0x90, 0x80,
-0x65, 0xE0, 0x44, 0xC2, 0xF0, 0x22
-};
-
/* LGS8GXX internal helper functions */
static int lgs8gxx_write_reg(struct lgs8gxx_state *priv, u8 reg, u8 data)
@@ -627,9 +592,14 @@ static int lgs8913_init(struct lgs8gxx_state *priv)
static int lgs8g75_init_data(struct lgs8gxx_state *priv)
{
-const u8 *p = lgs8g75_initdat;
+const struct firmware *fw;
+int rc;
int i;
+rc = request_firmware(fw, lgs8g75.fw, priv-i2c-dev);
+if (rc)
+return rc;
+
lgs8gxx_write_reg(priv, 0xC6, 0x40);
lgs8gxx_write_reg(priv, 0x3D, 0x04);
@@ -640,16 +610,16 @@ static int lgs8g75_init_data(struct lgs8gxx_state
*priv)
lgs8gxx_write_reg(priv, 0x3B, 0x00);
lgs8gxx_write_reg(priv, 0x38, 0x00);
-for (i = 0; i sizeof(lgs8g75_initdat); i++) {
+for (i = 0; i fw-size; i++) {
lgs8gxx_write_reg(priv, 0x38, 0x00);
lgs8gxx_write_reg(priv, 0x3A, (u8)(i0xff));
lgs8gxx_write_reg(priv, 0x3B, (u8)(i8));
-lgs8gxx_write_reg(priv, 0x3C, *p);
-p++;
+lgs8gxx_write_reg(priv, 0x3C, fw-data[i]);
}
lgs8gxx_write_reg(priv, 0x38, 0x00);
+release_firmware(fw);
return 0;
}
--
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
--
Cheers,
Mauro
--
To
RE: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Mauro, If you scan the patch, you would see the status of this patch series. --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) Not sure if there is a better way to include this information. The arch part of this series requires sign-off from Kevin who is copied on this. I have seen your procedure for submitting patches and would send you an official pull request as per your procedure once Kevin sign-off the arch part. I have following questions though.. Should we always add [RFC PATCH] in the subject? It makes sense for patches being reviewed. How to request sign-off? Do I only send patches to the person, not to the list? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Monday, February 01, 2010 6:12 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver m-kariche...@ti.com wrote: From: Murali Karicheri m-kariche...@ti.com This is the header file for ISIF driver on DM365. ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is tested for YUV capture from TVP514x driver. This patch contains the header files required for this driver. The name of the file is changed to reflect the name of IP. Reviewed-by: Nori, Sekhar nsek...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) - Updated based on comments against v1 of the patch (v2) drivers/media/video/davinci/isif_regs.h | 269 include/media/davinci/isif.h| 531 +++ 2 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h Hi Murali, As always, it is almost impossible for me to know if you're submitting yet another RFC version or a final version to be applied. So, I kindly ask you to send all those patches that are still under discussions with [RFC PATCH] at the subject, and, on the final version, send it to me via a git pull request. Unfortunately, I don't have enough time to go inside every RFC patch that are under discussion, so I prefer to optimize my time focusing on the patch versions that are considered ready for inclusion, and where there's no c/c to any members-only ML. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-usb-remote woes [was: HID: ignore afatech 9016]
Ok, that was it, I had the old firmware. Now it works with the patch. I can now see that the afateck driver does not use the HID interface/endpoint (1/83) at all, but vendor specific bulk endpoint (0/81). The fact that manufacturers have started to more more use the usb vendor class instead of the HID class is probably partly a consequence of HID specification being poorly designed. Oh, well. More work for driver writers. Anyway, I'm still of the opinion that the ir-to-code translate should be per remote controller not per tv-stick (ideally loaded by kernel from the userspace table, and easily modifiable by userspace program). All in all the remote controller stack is IMHO a real mess: different level translates (in kernel and in user space), different user program interfaces (keyboard with or without the special keys (many programs recognize only the standard keyboard keys), lircd direct, lircd/dcop). Really easiest is to modify kernel to get what you want. For average user the task of getting remote to do what they want is close to mission impossible. Hope someone would do something about this. Pekka Antti Palosaari wrote: On 02/01/2010 09:42 PM, Jiri Slaby wrote: On 02/01/2010 07:28 PM, Jiri Kosina wrote: On Mon, 1 Feb 2010, Pekka Sarnila wrote: I pulled few days ago latest git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git and compiled it. Everything works fine including the tv-stick and the remote. However I get: 3af9015: command failed:255 3dvb-usb: error while querying for an remote control event. Yes, I saw this quite recently too. For me it appears when it is booted up with the stick in. It's still to be fixed. I suspect you are using old firmware, 4.65.0.0 probably, that does not support remote polling and thus this 255 errors seen. regards Antti -- 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: dvb-usb-remote woes [was: HID: ignore afatech 9016]
Please, no mail to this address, use only sarn...@adit.fi. Pekka Antti Palosaari wrote: On 02/01/2010 09:42 PM, Jiri Slaby wrote: On 02/01/2010 07:28 PM, Jiri Kosina wrote: On Mon, 1 Feb 2010, Pekka Sarnila wrote: I pulled few days ago latest git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git and compiled it. Everything works fine including the tv-stick and the remote. However I get: 3af9015: command failed:255 3dvb-usb: error while querying for an remote control event. Yes, I saw this quite recently too. For me it appears when it is booted up with the stick in. It's still to be fixed. I suspect you are using old firmware, 4.65.0.0 probably, that does not support remote polling and thus this 255 errors seen. regards Antti -- 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: dvb-usb-remote woes [was: HID: ignore afatech 9016]
In the old kernel (2.6.24) it did not work if it was plugged while booting. If I recall right then it was due to the order different layers are initialized (modules loaded). Pekka Jiri Slaby wrote: On 02/01/2010 10:23 PM, Antti Palosaari wrote: On 02/01/2010 09:42 PM, Jiri Slaby wrote: On 02/01/2010 07:28 PM, Jiri Kosina wrote: On Mon, 1 Feb 2010, Pekka Sarnila wrote: 3af9015: command failed:255 3dvb-usb: error while querying for an remote control event. Yes, I saw this quite recently too. For me it appears when it is booted up with the stick in. It's still to be fixed. I suspect you are using old firmware, 4.65.0.0 probably, that does not support remote polling and thus this 255 errors seen. For me: af9013: firmware version:4.95.0 As I wrote, for me it happens iff it is plugged-in while booting. I'll investigate it further later -- that it a reason why I haven't reported it yet. -- 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] - tm6000 DVB support
Am 02.02.2010 00:05, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
Am 01.02.2010 22:44, schrieb Devin Heitmueller:
On Mon, Feb 1, 2010 at 4:23 PM, Stefan Ringel stefan.rin...@arcor.de
wrote:
You should start by breaking it down into a patch series, so that the
incremental changes can be reviewed. That will allow you to explain
in the patch descriptions why all the individual changes you have made
are required.
how can I generate it?
You can use quilt to break it up into a patch series, or create a
local hg clone of v4l-dvb.
Why did you define a new callback for changing the tuner mode? We
have successfully provided infrastructure on other bridges to toggle
GPIOs when changing modes. For example, the em28xx has fields in the
board profile that allow you to toggle GPIOs when going back and forth
between digital and analog mode.
I don't know, how you mean it. I'm amateur programmer.
Look at how the .dvb_gpio and .gpio fields are used in the board
profiles in em28xx-cards.c. We toggle the GPIOs when switching the
from analog to digital mode, without the tuner having to do any sort
of callback.
It's a bad example. em28xx use a reg-set, but tm6000 not !! It use a
gpio usb request.
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_5, 1);
I don't know, that it with the .gpio fields works. And when it switch
from analog to digital, I don't see the way.
All devices with Xceive tuners need to reset the chip via GPIO, in order to
load
the firmware. On em28xx, I wrote a patch that moved all specific init code to
a struct (basically used by gpio's), and a generic code to do the reset. It
basically
contains what GPIO pins are used, and how many time it should wait.
For example:
/* Board Hauppauge WinTV HVR 900 digital */
static struct em28xx_reg_seq hauppauge_wintv_hvr_900_digital[] = {
{EM28XX_R08_GPIO, 0x2e, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x04, 0x0f, 10},
{EM2880_R04_GPO,0x0c, 0x0f, 10},
{ -1, -1, -1, -1},
};
The first line of the above code will execute this logic:
a = read(EM28XXR08_GPIO) ~0x2e;
write (a ~EM_GPIO_4);
msleep(10);
So, it will basically preserve bits 8,7,6,4 and 1 of register 8,
and will clear bit 4 (EM_GPIO_4 is 1 4 - e. g. bit 4).
After that, it will sleep for 10 miliseconds, and will then do a
reset on bit 3 of Register 4 (writing 0, then 1 to the bit).
reset example :
static struct tm6010_seq terratec[] = {
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{TM6010_GPIO_2,0,75}, /* GPIO 2 going to lo */
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{ -1 ,-1,-1},
}
Is that correct?
What function does the tm6000 member in the zl10353 config do? It
doesn't seem to be used anywhere.
I'll switch it next week to demodulator module.
Are you saying the zl10353 isn't working right now in your patch? I'm
a bit confused. If it doesn't work, then your patch title is a bit
misleading since it suggests that your patch provides DVB support for
the tm6000. If it does work, then the tm6000 member shouldn't be
needed at all in the zl10353 config.
I'm emulating it in hack.c and the zl10353 module doesn't work, if I
switch to it.
the hack.c needs to be validated against the zl10353, in order to identify
what are the exact needs for tm6000. Some devices require serial mode, while
others require parallel mode.
I bet that playing with zl10353_config, we'll find the proper init values
required by tm6000.
I have separately write in the hack.c the value from terratec hybrid
stick. The older value I haven't clean.
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - tm6000 DVB support
Stefan Ringel wrote:
So, it will basically preserve bits 8,7,6,4 and 1 of register 8,
and will clear bit 4 (EM_GPIO_4 is 1 4 - e. g. bit 4).
After that, it will sleep for 10 miliseconds, and will then do a
reset on bit 3 of Register 4 (writing 0, then 1 to the bit).
reset example :
static struct tm6010_seq terratec[] = {
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{TM6010_GPIO_2,0,75}, /* GPIO 2 going to lo */
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{ -1 ,-1,-1},
}
Is that correct?
Yes. In the case of tm6010, it has separate registers for each GPIO, so, you
don't need a bitmask.
the hack.c needs to be validated against the zl10353, in order to identify
what are the exact needs for tm6000. Some devices require serial mode, while
others require parallel mode.
I bet that playing with zl10353_config, we'll find the proper init values
required by tm6000.
I have separately write in the hack.c the value from terratec hybrid
stick. The older value I haven't clean.
Ok, but maybe you missed my point: at the long term, we should get rid of
hack.c, and
be sure that all needed initializations are done by zl10353 driver or by
tm6010-dvb.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DM1105: could not attach frontend 195d:1105
On 2 февраля 2010 17:21:46 Nameer Kazzaz wrote:
Hi Igor,
What do you think ? if I can help you solve this, let me know what I
can do.
Thanks
Nameer
Nameer Kazzaz wrote:
Hi there,
dmesg output with patched dm1105.c against current v4l-dvb 'modprob
dm1105 card=4'
dm1105 :05:0f.0: PCI INT A - GSI 16 (level, low) - IRQ 16
DVB: registering new adapter (dm1105)
dm1105 :05:0f.0: MAC dd49b0dc
dm1105 :05:0f.0: could not attach frontend
dm1105 :05:0f.0: PCI INT A disabled
Thanks
Nameer Kazzaz
Igor M. Liplianin wrote:
On 20 ?? 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x // later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 // later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to
code
like that at the bottom. It still doesn't work, but feels a lot
closer.
Before I keep playing with values, I want to check I'm on the right
track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I
put the
logic into fe_attach because there was already card-specific logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input
= 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or
0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK, dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET ,
dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage function.
Try attached patch against current v4l-dvb tree with modprobe option
card=4
modprobe dm1105 card=4
Hi Nameer,
You can modify sended by me patch to guess GPIO pin. Simply try all of them, it
is only 17.
Just replace all appearances DM1105_GPIO(15) with number you want.
--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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
Re: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Karicheri, Muralidharan wrote: Mauro, If you scan the patch, you would see the status of this patch series. Ok, but it is not script-able. So, I need to have an easy way to know when a patch is still under discussion at the ML or if it is ready for merging. I need something that I can write an script on my machine to update Patchwork status and remove the stuff that are still under discussions from my pull queue. On most cases, the level of detail between two revisions of the omap drivers are due to some intrinsic details of the driver or the arch. So, it makes no sense for me to keep checking all reviews. I would love to, but unfortunately I have no spare time for it. That's why I prefer to review only the final revision, when the patch is submitted. --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) Not sure if there is a better way to include this information. The arch part of this series requires sign-off from Kevin who is copied on this. I have seen your procedure for submitting patches and would send you an official pull request as per your procedure once Kevin sign-off the arch part. The pull request is enough for me. I'll review when I receive it. I have following questions though.. Should we always add [RFC PATCH] in the subject? It makes sense for patches being reviewed. How to request sign-off? Do I only send patches to the person, not to the list? For the patches exchanged via the ML, I need some scriptable way to mark them as RFC at the Patchwork. So, adding [RFC PATCH] or [PATCH RFC] works. It also works if you add something like [PATCH OMAP] or [PATCH OMAP V4L], and provided that all other contributors to the patches you'll be sending me a pull request do exactly the same. I'll then write an specific script to mark those patches as RFC and remove from my queue, until I receive your [PULL] request. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - tm6000 DVB support
Am 01.02.2010 23:52, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
add Terratec Cinergy Hybrid XE
bugfix i2c transfer
add frontend callback
add init for tm6010
add digital-init for tm6010
add callback for analog/digital switch
bugfix usb transfer in DVB-mode
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
Devin is right with respect to the changes: you should break into small
patches for us to better understand what you're doing.
In particular, some parts of the changes (like tuner-xc2028) are known
to be working fine with other drivers, so any change there should be done
with the enough care to not break other drivers.
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..2297c00 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -15,6 +15,7 @@
#include linux/delay.h
#include media/tuner.h
#include linux/mutex.h
+#include compat.h
#include asm/unaligned.h
#include tuner-i2c.h
#include tuner-xc2028.h
@@ -994,6 +995,13 @@ static int generic_set_freq(struct dvb_frontend
*fe, u32 freq /* in HZ */,
buf[0], buf[1], buf[2], buf[3],
freq / 100, (freq % 100) / 1000);
+if (priv-ctrl.switch_mode) {
+if (new_mode == T_ANALOG_TV)
+do_tuner_callback(fe, SWITCH_TV_MODE, 0);
+if (new_mode == T_DIGITAL_TV)
+do_tuner_callback(fe, SWITCH_TV_MODE, 1);
+}
+
rc = 0;
The decision taken at the driver were the opposite: the bridge driver should
have the logic to reset the tuner. This works perfectly on em28xx and other
drivers that use xc3028.
I don't see a good reason to revert the logic here. Also, such change should
be done on all drivers that use xc3028 and xc5000.
ret:
@@ -1114,7 +1122,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
-demod = priv-ctrl.demod + 200;
+if (priv-ctrl.fname == xc3028L-v36.fw) {
+demod = priv-ctrl.demod;
+} else {
+demod = priv-ctrl.demod + 200;
+}
Instead, you should be using the firmware version.
As the firmware version is written at the firmware file, it is easy to do the
tests
based on the firmware version, even on devices like tm6000 where the version
read
method may fail.
Not with the i2c patch, see down.
Yet, I suspect that the currently available v36 firmwares already take this
into
consideration (or the drivers that use those firmwares do the offset
internally).
So, this change needs to be checked against the existing drivers.
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
@@ -1123,8 +1135,8 @@ static int xc2028_set_params(struct dvb_frontend *fe,
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
*/
-if (type DTV7)
-demod += 500;
+if (type DTV7)
+demod += 500;
This hunk is wrong.
Why that generated the git diff, I cannot say. It must be the older once.
}
return generic_set_freq(fe, p-frequency,
@@ -1240,6 +1252,10 @@ static const struct dvb_tuner_ops
xc2028_dvb_tuner_ops = {
.get_rf_strength = xc2028_signal,
.set_params= xc2028_set_params,
.sleep = xc2028_sleep,
+#if 0
+int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
+int (*get_status)(struct dvb_frontend *fe, u32 *status);
+#endif
};
struct dvb_frontend *xc2028_attach(struct dvb_frontend *fe,
diff --git a/drivers/media/common/tuners/tuner-xc2028.h
b/drivers/media/common/tuners/tuner-xc2028.h
index 9778c96..c9a4fb4 100644
--- a/drivers/media/common/tuners/tuner-xc2028.h
+++ b/drivers/media/common/tuners/tuner-xc2028.h
@@ -42,6 +42,7 @@ struct xc2028_ctrl {
unsigned intdisable_power_mgmt:1;
unsigned intread_not_reliable:1;
unsigned intdemod;
+unsigned intswitch_mode:1;
This struct is meant to pass static parameters to the driver. the
analog/digital
mode is dynamic, so, this is not the right place for doing it.
Can you tell me how that work? Where would call it? Switch it after read
demodulator status or before? This switch switches the tuner output to
the demodulator or adc input and if it read status before it switch
thoughts the apps no digital found.
enum firmware_typetype:2;
};
@@ -54,6 +55,7 @@ struct xc2028_config {
/* xc2028 commands for callback */
#define XC2028_TUNER_RESET0
#define XC2028_RESET_CLK1
+#define SWITCH_TV_MODE2
#if defined(CONFIG_MEDIA_TUNER_XC2028) ||
Re: [PATCH] - tm6000 DVB support
Am 02.02.2010 17:44, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
So, it will basically preserve bits 8,7,6,4 and 1 of register 8,
and will clear bit 4 (EM_GPIO_4 is 1 4 - e. g. bit 4).
After that, it will sleep for 10 miliseconds, and will then do a
reset on bit 3 of Register 4 (writing 0, then 1 to the bit).
reset example :
static struct tm6010_seq terratec[] = {
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{TM6010_GPIO_2,0,75}, /* GPIO 2 going to lo */
{TM6010_GPIO_2,1,60}, /* GPIO 2 going to high */
{ -1 ,-1,-1},
}
Is that correct?
Yes. In the case of tm6010, it has separate registers for each GPIO, so, you
don't need a bitmask.
the hack.c needs to be validated against the zl10353, in order to identify
what are the exact needs for tm6000. Some devices require serial mode, while
others require parallel mode.
I bet that playing with zl10353_config, we'll find the proper init values
required by tm6000.
I have separately write in the hack.c the value from terratec hybrid
stick. The older value I haven't clean.
Ok, but maybe you missed my point: at the long term, we should get rid of
hack.c, and
be sure that all needed initializations are done by zl10353 driver or by
tm6010-dvb.
I think I all are done by zl10353 driver.
I thinbk all config param is usefull and .tm6000 for tm6000 specific
once. For what is .parallel_ts ?
int tm6000_dvb_attach_frontend(struct tm6000_core *dev)
{
struct tm6000_dvb *dvb = dev-dvb;
if(dev-caps.has_zl10353) {
struct zl10353_config config =
{.demod_address = dev-demod_addr,
.no_tuner = 1,
.parallel_ts = 1,
.if2 = 45700,
.disable_i2c_gate_ctrl = 1,
.tm6000 = 1,
};
dvb-frontend = pseudo_zl10353_attach(dev, config,
//dvb-frontend = dvb_attach (zl10353_attach, config,
dev-i2c_adap);
}
else {
printk(KERN_ERR tm6000: no frontend defined for the device!\n);
return -1;
}
return (!dvb-frontend) ? -1 : 0;
}
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Karicheri, Muralidharan wrote: Mauro, How to request sign-off? Do I only send patches to the person, not to the list? I think you have not answered this. For the patches exchanged via the ML, I need some scriptable way to mark them as RFC at the Patchwork. So, adding [RFC PATCH] or [PATCH RFC] works. It also works if you add something like [PATCH OMAP] or [PATCH OMAP V4L], and provided that all other contributors to the patches you'll be sending me a pull request do exactly the same. Not sure what the last part of your statement (beginning with provided that) means. I mean: the better is if everybody sending such patches to do the same way. So, it would be really good if all traffic at the ML for those RFC patches to have the same tag. The patches always go through multiple iterations. In future I will add [RFC PATCH] for such patches. But this request was sent to Kevin to ack my patches so that I can send a pull request. How do I handle this? A direct email to Kevin without copying to linux-media ? You don't need to c/c the linux-media ML for it, but, of course you can do it. Anyway, at the pull requests that are touching on arch, please C/C the arch maintainer on it (even having their SOB). This will help them to track what's happening on the files under their responsibility. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] libv4l: skip false Pixart markers
Hans de Goede wrote:
Hi,
On 02/01/2010 11:13 PM, Németh Márton wrote:
From: Márton Némethnm...@freemail.hu
The byte sequence 0xff, 0xff, 0xff 0xff is not a real marker to skip, instead
it is one byte from the image and the following three 0xff bytes might belong
to a real marker. Modify pixart_fill_nbits() macro to pass the first 0xff
byte
as an image data.
Oh, good catch. I'm still seeing the occasional bad frame though :(
The same at my side, this patch alone does not solve the whole problem complete.
I have the feeling that at least same of the corrupted frames will not come with
this patch, through I haven't verified this with measurement.
On the other hand, in my previous email used a little bit different code: I
jumped
over the 1024 and 512 bytes without parsing it. That would be maybe necessary
to add.
By the way, is there any reason why pixart_fill_nbits() is a macro?
While on the subject of the pac7302. I've been playing around a bit, and I
have the
feeling that if we were to go for a lower auto gain target (set autogain off
and
lower exposure, you can do this ie with v4l2ucp), combined with a gamma
correction of
1500 (again use ie v4l2ucp), the images is much better (less over exposed,
more
contrast).
Do you agree ?
Well, my Labtec Webcam 2200 works only with acceptable indoors, when I try to
capture something outdoors under direct sunshine conditions I get overexposed
frames. I found, however, an interesting pointer in two cameras' user's manual,
see the Note column:
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification
There is a setting indoor/outdoor which is currently not available in
gspca_pac7302
driver. Maybe this would be an interesting point to figure out which register
is related to this setting.
Regards,
Márton Németh
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r f23c5a878fb1 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 13:32:46
2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Mon Feb 01 23:05:39
2010 +0100
@@ -339,10 +339,15 @@
} \
break; \
case 0xff: \
-if (stream[1] == 0xff (stream[2] 7 || stream[2] == 0xff)) { \
- stream += 3; \
- c = *stream++; \
- break; \
+if (stream[1] == 0xff) { \
+if (stream[2] 7) { \
+stream += 3; \
+c = *stream++; \
+break; \
+} else if (stream[2] == 0xff) { \
+/* four 0xff in a row: the first belongs to the image data
*/ \
+break; \
+}\
} \
/* Error fall through */ \
default: \
--
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: libv4l: possible problem found in PAC7302 JPEG decoding
Hi Thomas, Thomas Kaiser wrote: On 02/01/2010 10:23 PM, Németh Márton wrote: Hello Hans, while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the following behaviour. The stream received from the webcam is splitted by the gspca_pac7302 subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()). Before transmitting the data to the userspace a JPEG header is added (pac_start_frame()) and the footer after the bytes 0xff, 0xd9 are removed. The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact): 1. JPEG header 2. Some bytes of image data (near to 1024 bytes) 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data. This marker sequence and data repeats a couple of time. Exactly how much depends on the image content. 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data. This marker sequence and data also repeats a couple of time. 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of image data bytes. 6. The End of Image (EOI) marker 0xff, 0xd9. Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff, 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then the three 0xff bytes from the marker is also removed. The xx (which really belongs to the marker) is left in the image data instead of the original 0xff byte. Based on my experiments this problem sometimes causes corrupted image decoding or that the JPEG image cannot be decoded at all. Hello Németh I remember the problem as I was working on the PAC7311. http://www.kaiser-linux.li/index.php?title=PAC7311 This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 0xnn markers. See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz decoder/gspcadecoder.c pac7311_decode() Do you remember whether this code was working properly always? 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
Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Jean, From: Jean Delvare kh...@linux-fr.org Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type, and run saa7134_input_init1(). Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Daro ghost-ri...@aster.pl Cc: Roman Kellner muzu...@gmx.net --- linux/drivers/media/video/saa7134/saa7134-cards.c |5 + 1 file changed, 5 insertions(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-30 10:56:50.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-30 11:52:18.0 +0100 @@ -7299,6 +7299,11 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO %s: P7131 analog only, using entry of %s\n, dev-name, saa7134_boards[dev-board].name); + + /* IR init has already happened for other cards, so + * we have to catch up. */ + dev-has_remote = SAA7134_REMOTE_GPIO; + saa7134_input_init1(dev); } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: This version of your patch makes sense to me. This logic will only apply for board SAA7134_BOARD_ASUSTeK_P7131_ANALOG, so, provided that someone with this board test it, I'm OK with it. Had Roman or Daro already test it? -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Feb 2 19:00:06 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14096:860d29bfa3a7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.17-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: libv4l: possible problem found in PAC7302 JPEG decoding
On 02/02/2010 07:59 PM, Németh Márton wrote: Hi Thomas, Thomas Kaiser wrote: On 02/01/2010 10:23 PM, Németh Márton wrote: Hello Hans, while I was dealing with Labtec Webcam 2200 and with gspca_pac7302 driver I recognised the following behaviour. The stream received from the webcam is splitted by the gspca_pac7302 subdriver when the byte sequence 0xff, 0xff, 0x00, 0xff, 0x96 is found (pac_find_sof()). Before transmitting the data to the userspace a JPEG header is added (pac_start_frame()) and the footer after the bytes 0xff, 0xd9 are removed. The data buffer which arrives to userspace looks like as follows (maybe not every detail is exact): 1. JPEG header 2. Some bytes of image data (near to 1024 bytes) 3. The byte sequence 0xff, 0xff, 0xff, 0x01 followed by 1024 bytes of data. This marker sequence and data repeats a couple of time. Exactly how much depends on the image content. 4. The byte sequence 0xff, 0xff, 0xff, 0x02 followed by 512 bytes of data. This marker sequence and data also repeats a couple of time. 5. The byte sequence 0xff, 0xff, 0xff, 0x00 followed by a variable amount of image data bytes. 6. The End of Image (EOI) marker 0xff, 0xd9. Now what can be wrong with the libv4l? In libv4lconvert/tinyjpeg.c, line 315 there is a huge macro which tries to remove the 0xff, 0xff, 0xff, xx byte sequence from the received image. This fails, however, if the image contains 0xff bytes just before the 0xff, 0xff, 0xff, xx sequence because one byte from the image data (the first 0xff) is removed, then the three 0xff bytes from the marker is also removed. The xx (which really belongs to the marker) is left in the image data instead of the original 0xff byte. Based on my experiments this problem sometimes causes corrupted image decoding or that the JPEG image cannot be decoded at all. Hello Németh I remember the problem as I was working on the PAC7311. http://www.kaiser-linux.li/index.php?title=PAC7311 This is the code I used in the JPEG decoder to remove the 0xff 0xff 0xff 0xnn markers. See http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz decoder/gspcadecoder.c pac7311_decode() Do you remember whether this code was working properly always? Hello Németh I am not 100% sure but it looked OK for me. Anyway, we have to throw away these markers before the JPEG decoding starts. I don't think this code will fail when you parse the Byte stream (frame header removed before!). We don't know these markers, so we don't need them. Thomas -- 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] - tm6000 DVB support
Stefan Ringel wrote:
Am 01.02.2010 23:52, schrieb Mauro Carvalho Chehab:
This struct is meant to pass static parameters to the driver. the
analog/digital
mode is dynamic, so, this is not the right place for doing it.
Can you tell me how that work? Where would call it? Switch it after read
demodulator status or before? This switch switches the tuner output to
the demodulator or adc input and if it read status before it switch
thoughts the apps no digital found.
Basically, this is done by check_firmware. It is called by
xc2028_set_analog_freq()
or
xc2028_set_params()
So, when the frontend (digital) or the tuner (analog) is called to set an
analog frequency
or to set DVB parameters.
All that it is needed for this to work is that both analog and DVB part should
call
xc2028_attach() with the proper parameters.
For the analog side, you need a code like that (modified from em28xx-cards.c):
if ((dev-tuner_type != TUNER_ABSENT) (dev-tuner_type)) {
tun_setup.type = TUNER_XC2028;
tun_setup.addr = dev-tuner_addr;
v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_type_addr,
tun_setup);
}
With this code, tuner-core set_type() will register the analog side of the
driver.
For the digital part, you need to call xc2028_attach() manually (from
em28xx-dvb):
fe = dvb_attach(xc2028_attach, dev-dvb-frontend, cfg);
When the driver wants to switch to an specific mode, all it needs is to set an
analog or
digital frequency. The frontend or tuner driver will do the rest.
@@ -45,6 +45,8 @@ struct zl10353_config
/* clock control registers (0x51-0x54) */
u8 clock_ctl_1; /* default: 0x46 */
u8 pll_0;/* default: 0x15 */
+
+int tm6000:1;
This doesn't make sense. The zl10353 doesn't need to know if the device is
a tm6000 or not. If the tm6000 driver needs something special, then we need
to discover what he is doing and name the zl10353 feature accordingly.
that is for todo in next week, when I switch from hack.c to zl10353
kernel module, but it can remove if it don't use.
OK.
+tm6000_read_write_usb(tm6000_dev,0xc0,0x10,0x0b1f,0,data,2);
+printk(KERN_INFO buf %#x %#x \n, data[0], data[1]);
+msleep(40);
The same comment here: maybe the above code only applies to tm6010.
It little different to the other hack code. The lastest lines are
reading demod status.
If you're reading the demod status, the proper way is to call the corresponding
code at the tm6000-dvb part and use the standard i2c way of doing it.
The demod status depends on what demod you have, so the code there should be
board dependent. While currently only one demod is supported, there are devices
like Nova-S USB that have different demods (the Nova-S is DVB-S).
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -32,7 +32,7 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
-#include tuner-xc5000.h
+#include xc5000.h
Please send this hunk on a separate patch. Since it fixes compilation, I'll
need to apply it before the Kconfig changes, when tm6000 upstream.
o.k. but I cannot know how. I have no idea with diff or something.
The better way is to clone a tree and write your patches there, committing every
patch.
If you want to break an already existing diff into small diffs, you may copy it
by hand and remove the uneeded hunks.
For example, if you just save this into a file:
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -32,7 +32,7 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
-#include tuner-xc5000.h
+#include xc5000.h
#define TM6000_BOARD_UNKNOWN 0
#define TM5600_BOARD_GENERIC 1
and apply to your new tree, you'll have just one change there.
A hunk starts with @@. the numbers after - are the line number and the number
of lines
of the original code. The numbers after + are the line number/line count
after the patch.
For example, on this hunk:
@@ -402,6 +448,7 @@ static int tm6000_init_dev(struct tm6000_core *dev)
}
#endif
}
+ return 0;
err2:
v4l2_device_unregister(dev-v4l2_dev);
It is changing the content of line number 402 of the source code. The original
code has 6 lines
(the 3 lines before and the 3 lines after the insertion). It is adding one line
(the line with +).
The resulting code will be at line #448 and will have 7 lines.
If you copy the above, plus the name of the file to patch (the lines with ---
and +++):
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -402,6 +448,7 @@ static int tm6000_init_dev(struct tm6000_core *dev)
}
#endif
}
+ return 0;
err2:
v4l2_device_unregister(dev-v4l2_dev);
You'll have a patch that just adds return 0.
On
Re: [PATCH] - tm6000 DVB support
Stefan Ringel wrote:
Ok, but maybe you missed my point: at the long term, we should get rid of
hack.c, and
be sure that all needed initializations are done by zl10353 driver or by
tm6010-dvb.
I think I all are done by zl10353 driver.
I thinbk all config param is usefull and .tm6000 for tm6000 specific
once. For what is .parallel_ts ?
zl10353 may be connected via a serial or via a parallel interface to the chip.
So, it basically depends on how the wiring between zl10353 and the bridge is
done.
int tm6000_dvb_attach_frontend(struct tm6000_core *dev)
{
struct tm6000_dvb *dvb = dev-dvb;
if(dev-caps.has_zl10353) {
struct zl10353_config config =
{.demod_address = dev-demod_addr,
.no_tuner = 1,
.parallel_ts = 1,
.if2 = 45700,
.disable_i2c_gate_ctrl = 1,
.tm6000 = 1,
};
dvb-frontend = pseudo_zl10353_attach(dev, config,
//dvb-frontend = dvb_attach (zl10353_attach, config,
dev-i2c_adap);
}
else {
printk(KERN_ERR tm6000: no frontend defined for the device!\n);
return -1;
}
return (!dvb-frontend) ? -1 : 0;
}
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Updated procedures for patch submission
Updates the procedures to reflect the -git tree support on LinuxTV. The previous version of the document were already a little outdated, since it assumed that all patches were sent via -hg. So, email submission weren't mentioned. Also it used to mix mercurial procedures with best practices. With the usage of -git, the document needs to be reviewed, to incorporate the new procedures. Basically the changes on this document does: - Add the git procedures submitted for RFC, and updated at LinuxTV wiki: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees - Move the procedures specific to -hg to a separate section; - Add a general explanation about patch management; - Add git specific procedures; - Add mail submission procedures. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/README.patches b/README.patches --- a/README.patches +++ b/README.patches @@ -1,5 +1,5 @@ Mauro Carvalho Chehab mchehab at infradead dot org - Updated on 2009 February 9 + Updated on 2010 January 30 This file describes the general procedures used by the LinuxTV team (*) and by the v4l-dvb community. @@ -13,58 +13,135 @@ TV and radio broadcast AM/FM. CONTENTS - 1. A brief introduction about patch management - 2. Git trees' relationships with v4l/dvb development - 3. Mercurial trees used for v4l/dvb development - 4. Community best practices - 5. Knowing about newer patches committed at master hg repository - 6. Patch handling for kernel submission - 7. Patch submission from the community - 8. Identifying regressions with Mercurial - 9. Creating a newer driver + Part I - Patch management on LinuxTV +1. A brief introduction about patch management + 2. Git and Mercurial trees hosted on LinuxTV site +3. Git and Mercurial trees' relationships with v4l/dvb development +4. Patch submission process overall +5. Other Git trees used for v4l/dvb development +6. Other Mercurial trees used for v4l/dvb development + + Part II - Git trees +1. Kernel development procedures at the kernel upstream + 1.1 Subsystem procedures for merging patches upstream + 1.2 A practical example + 1.3 Patches for stable +2. Kernel development procedures for V4L/DVB + 2.1 Fixes and linux-next patches + 2.2 How to solve those issues? +3. How to submit a -git pull request + 3.1 Tags that a patch receive after its submission +4. Patches submitted via email + 4.1 Example + + Part III - Best Practices +1. Community best practices +2. Mercurial specific procedures +3. Knowing about newer patches committed at the development repositories +4. Patch submission from the community +5. Identifying regressions with Mercurial +6. Identifying regressions with Git +7. Creating a newer driver + 7.1. Simple drivers + 7.2. Bigger drivers + +=== +PART I. PATCH MANAGEMENT ON LINUXTV +=== + 1. A brief introduction about patch management - == + === -Current V4L/DVB development is based on a modern SCM system that -fits better into kernel development model, called Mercurial (aka hg). +V4L/DVB development is based on modern SCM (Source Code Management) systems +that fits better into kernel development model. -Kernel development model is based on a similar SCM, called git. While -very powerful for distributed development, git usage is not simple for -final users. That's the reason why hg was selected for V4L/DVB -development. +At the beginning, the usage CVS for of a SCM (Source Code Management) were +choosen on V4L/DVB. Both of the original V4L and DVB trees were developed with +the help of cvs. On that time, upstream Linux kernel used to have another tree +(BitKeeper). -There are some tutorials, FAQs and other valuable information at -http://selenic.com/mercurial/ about hg usage. +In 2005, Upstream Kernel development model changed to use git (a SCM tool +developed by Linus Torvalds, the inventor and main maintainer of the Linux +Kernel). -Mercurial is a distributed SCM, which means every developer gets his -own full copy of the repository (including the complete revision -history), and can work and commit locally without network connection. -The resulting changesets can then be exchanged between repositories and -finally merged into a common repository on linuxtv.org. +Also in 2005, both V4L and DVB trees got merged into one cvs repository, and +the community discussed about what would be the better SCM solution. It were +mainly availed the usage of svn, hg and git. On that time, both hg and git were +new technologies, based on
Re: [PATCH] - tm6000 DVB support
Am 02.02.2010 21:03, schrieb Mauro Carvalho Chehab:
Those tuner callback initializations are board-specific. So, it is better
to test
for your board model, if you need something different than what's currently
done.
This tuner reset works with my stick, but I think that can test with
other tm6000 based sticks and if it not works then I can say this as a
board-specific.
It won't work on my boards. The GPIO pin used by each board is different.
Have you the right gpio pin in the card struct. I have the
.gpio_addr_tun_reset the correct gpio pin
[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+.name = Terratec Cinergy Hybrid XE,
+.tuner_type = TUNER_XC2028, /* has a XC3028 */
+.tuner_addr = 0xc2 1,
+.demod_addr = 0x1e 1,
+.type = TM6010,
+.caps = {
+.has_tuner= 1,
+.has_dvb = 1,
+.has_zl10353 = 1,
+.has_eeprom = 1,
+.has_remote = 1,
+},
+.gpio_addr_tun_reset = TM6010_GPIO_2, /* here */
+}
};
--
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] - tm6000 DVB support
Stefan Ringel wrote:
Am 02.02.2010 21:03, schrieb Mauro Carvalho Chehab:
Those tuner callback initializations are board-specific. So, it is better
to test
for your board model, if you need something different than what's
currently done.
This tuner reset works with my stick, but I think that can test with
other tm6000 based sticks and if it not works then I can say this as a
board-specific.
It won't work on my boards. The GPIO pin used by each board is different.
Have you the right gpio pin in the card struct. I have the
.gpio_addr_tun_reset the correct gpio pin
[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+.name = Terratec Cinergy Hybrid XE,
+.tuner_type = TUNER_XC2028, /* has a XC3028 */
+.tuner_addr = 0xc2 1,
+.demod_addr = 0x1e 1,
+.type = TM6010,
+.caps = {
+.has_tuner= 1,
+.has_dvb = 1,
+.has_zl10353 = 1,
+.has_eeprom = 1,
+.has_remote = 1,
+},
+.gpio_addr_tun_reset = TM6010_GPIO_2, /* here */
+}
};
Ok, this works :) All needed pins should be customized there, either
individually
or via an struct similar to the one done at em28xx driver. Both ways have
advantages
and disadvantages.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hi, Hans Verkuil wrote: This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. [snip] Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log linux-2.6.16.62-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:48:29: error: linux/usb/input.h: No such file or directory /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:182: warning: implicit declaration of function 'usb_to_input_id' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.17.14-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:48:29: error: linux/usb/input.h: No such file or directory /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:182: warning: implicit declaration of function 'usb_to_input_id' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.18.8-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: request for member 'parent' in something not a structure or union /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: request for member 'parent' in something not a structure or union linux-2.6.19.7-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' linux-2.6.20.21-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' linux-2.6.21.7-i686: ERRORS /home/hans/work/build/v4l-dvb-master/v4l/gspca.c: In function 'gspca_input_connect': /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:186: error: 'struct input_dev' has no member named 'dev' /home/hans/work/build/v4l-dvb-master/v4l/gspca.c:192: error: 'struct input_dev' has no member named 'dev' It seems that the camera button input support is not compatible with kernel version 2.6.21.7 and before because of different reasons. 1. Between 2.6.16.62 and 2.6.17.14: there is no linux/usb/input.h . The linux/usb/input.h was earlier linux/usb_input.h, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/usb/input.h;h=0e010b220e85b3f9ea861f2ab009809d17014910;hb=HEAD 2. Between 2.6.16.62 and 2.6.17.14: there is no 'usb_to_input_id'. This was introduced with the commit 16a334c0de5a94b1d10a1ac9a33f4dedac89a075, exactly in the same place: in linux/usb_input.h . http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=16a334c0de5a94b1d10a1ac9a33f4dedac89a075 3. Between 2.6.16.62 and 2.6.18.8: there is no 'parent' field of struct device. The struct device is defined in linux/device.h . I couldn't find what exactly happened here, yet. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/device.h;h=a62799f2ab0019863d30e4f55f7677c5bd97d124;hb=HEAD 4. Between linux-2.6.19.7 and 2.6.21.7: 'struct input_dev' has no member named 'dev'. The 'dev' member was introduced with commit 9657d75c5f0f7d0a9cb507521d3ad1436aea28c9 when a convert was made from class devices to standard devices. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9657d75c5f0f7d0a9cb507521d3ad1436aea28c9 The main question is that does gspca need to support kernel version 2.6.21.7 and before? If yes, then should the input support disabled in 2.6.21.7 and before? 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
Re: [PATCH] - tm6000 DVB support
Am 02.02.2010 21:03, schrieb Mauro Carvalho Chehab:
@@ -404,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+u8 buf[40];
Why 40 ? Please avoid using magic numbers here, especially if you're
not checking at the logic if you're writing outside the buffer.
It important for tm6010 init sequence to enable the demodulator, because
the demodulator haven't found after init tuner.
Probably, there is some i2c gate to enable/disable the i2c access to the
demodulator. The better way is to add a call to the tm6000-dvb and let it
init the demodulator.
Also, since there's a gate for the demodulator, the proper way is to add
a callback to control it. Please take a look at saa7134 and seek for
i2c_gate_ctrl
to see how such logic works.
It has followed structure schema without the GPIOs:
1. tm6010 init
2. enable zl10353
3. tm6010 re-init
If it board specific then it's better when board number definition
switch from tm6000-card.c to tm6000.h . We can use in all tm6000*.c
files the board definition .
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - tm6000 DVB support
Stefan Ringel wrote:
Am 02.02.2010 21:03, schrieb Mauro Carvalho Chehab:
@@ -404,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+u8 buf[40];
Why 40 ? Please avoid using magic numbers here, especially if you're
not checking at the logic if you're writing outside the buffer.
It important for tm6010 init sequence to enable the demodulator, because
the demodulator haven't found after init tuner.
Probably, there is some i2c gate to enable/disable the i2c access to the
demodulator. The better way is to add a call to the tm6000-dvb and let it
init the demodulator.
Also, since there's a gate for the demodulator, the proper way is to add
a callback to control it. Please take a look at saa7134 and seek for
i2c_gate_ctrl
to see how such logic works.
It has followed structure schema without the GPIOs:
1. tm6010 init
2. enable zl10353
3. tm6010 re-init
If it board specific then it's better when board number definition
switch from tm6000-card.c to tm6000.h . We can use in all tm6000*.c
files the board definition .
What's board specific: all stuff that has GPIO, and the demod/frontend enable
code.
In order to have a better structure, the demod/frontend enable code should be
at the tm6000-dvb,
just like the other drivers. There, you'll have a switch for those devices that
have DVB
(Among others, I have here one 10moons device that is analog-only, with a
tm5600 - a stripped
down version of tm6000, without the DVB part).
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] - tm6000 DVB support
Am 02.02.2010 21:52, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
Am 02.02.2010 21:03, schrieb Mauro Carvalho Chehab:
@@ -404,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+u8 buf[40];
Why 40 ? Please avoid using magic numbers here, especially if you're
not checking at the logic if you're writing outside the buffer.
It important for tm6010 init sequence to enable the demodulator, because
the demodulator haven't found after init tuner.
Probably, there is some i2c gate to enable/disable the i2c access to the
demodulator. The better way is to add a call to the tm6000-dvb and let it
init the demodulator.
Also, since there's a gate for the demodulator, the proper way is to add
a callback to control it. Please take a look at saa7134 and seek for
i2c_gate_ctrl
to see how such logic works.
It has followed structure schema without the GPIOs:
1. tm6010 init
2. enable zl10353
3. tm6010 re-init
If it board specific then it's better when board number definition
switch from tm6000-card.c to tm6000.h . We can use in all tm6000*.c
files the board definition .
What's board specific: all stuff that has GPIO, and the demod/frontend enable
code.
In order to have a better structure, the demod/frontend enable code should be
at the tm6000-dvb,
just like the other drivers. There, you'll have a switch for those devices
that have DVB
(Among others, I have here one 10moons device that is analog-only, with a
tm5600 - a stripped
down version of tm6000, without the DVB part).
I have additional information to enable demodulator, it must enable
before firmware load after that it cannot find zl10353, I think. Should
I test it!
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support for Twinhan 1027 DVB-S card (once again)
This patch is the modified version of sfstudio (Denis Romanenko) patch, adapted for current mercurial revision. Previous patch seems to be broken. So submit once again. -- WBR Sergey Kash Ivanov. vp1027.patch Description: Binary data
Re: DM1105: could not attach frontend 195d:1105
Nameer Kazzaz wrote:
Igor M. Liplianin wrote:
On 2 февраля 2010 17:21:46 Nameer Kazzaz wrote:
Hi Igor,
What do you think ? if I can help you solve this, let me know
what I
can do.
Thanks
Nameer
Nameer Kazzaz wrote:
Hi there,
dmesg output with patched dm1105.c against current v4l-dvb 'modprob
dm1105 card=4'
dm1105 :05:0f.0: PCI INT A - GSI 16 (level, low) - IRQ 16
DVB: registering new adapter (dm1105)
dm1105 :05:0f.0: MAC dd49b0dc
dm1105 :05:0f.0: could not attach frontend
dm1105 :05:0f.0: PCI INT A disabled
Thanks
Nameer Kazzaz
Igor M. Liplianin wrote:
On 20 ?? 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x //
later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 //
later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to
code
like that at the bottom. It still doesn't work, but feels a lot
closer.
Before I keep playing with values, I want to check I'm on the right
track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I
put the
logic into fe_attach because there was already card-specific
logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input
= 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or
0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK,
dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET ,
dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage
function.
Try attached patch against current v4l-dvb tree with modprobe option
card=4
modprobe dm1105 card=4
Hi Nameer,
You can modify sended by me patch to guess GPIO pin. Simply try all
of them, it is only 17. Just replace all appearances DM1105_GPIO(15)
with number you want.
Ok I will do that.
Thanks
Nameer
Hi Igor,
I tried all DM1105_GPIO(0) to DM1105_GPIO(17), same error. Any Idea ?
Nameer
--
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/7] drivers/media/video/Kconfig: add VIDEO_DEV dependency as needed in drivers/media/video/Kconfig
From: Mike Pagano mpag...@gentoo.org Add VIDEO_DEV as dependency of VIDEO_CAPTURE_DRIVERS and all of the devices listed under this setting. Signed-off-by: Mike Pagano mpag...@gentoo.org Cc: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/video/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff -puN drivers/media/video/Kconfig~drivers-media-video-kconfig-add-video_dev-dependency-as-needed-in-drivers-media-video-kconfig drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig~drivers-media-video-kconfig-add-video_dev-dependency-as-needed-in-drivers-media-video-kconfig +++ a/drivers/media/video/Kconfig @@ -51,14 +51,14 @@ config VIDEO_TUNER menuconfig VIDEO_CAPTURE_DRIVERS bool Video capture adapters - depends on VIDEO_V4L2 + depends on VIDEO_V4L2 VIDEO_DEV default y ---help--- Say Y here to enable selecting the video adapters for webcams, analog TV, and hybrid analog/digital TV. Some of those devices also supports FM radio. -if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 +if VIDEO_DEV VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 config VIDEO_ADV_DEBUG bool Enable advanced debug functionality @@ -500,7 +500,7 @@ endmenu # encoder / decoder chips config DISPLAY_DAVINCI_DM646X_EVM tristate DM646x EVM Video Display - depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + depends on MACH_DAVINCI_DM6467_EVM select VIDEOBUF_DMA_CONTIG select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 @@ -513,7 +513,7 @@ config DISPLAY_DAVINCI_DM646X_EVM config CAPTURE_DAVINCI_DM646X_EVM tristate DM646x EVM Video Capture - depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + depends on MACH_DAVINCI_DM6467_EVM select VIDEOBUF_DMA_CONTIG select VIDEO_DAVINCI_VPIF help @@ -533,7 +533,7 @@ config VIDEO_DAVINCI_VPIF config VIDEO_VIVI tristate Virtual Video Driver - depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 + depends on VIDEO_V4L2 !SPARC32 !SPARC64 select VIDEOBUF_VMALLOC default n ---help--- @@ -889,7 +889,7 @@ config MX1_VIDEO config VIDEO_MX1 tristate i.MX1/i.MXL CMOS Sensor Interface driver - depends on VIDEO_DEV ARCH_MX1 SOC_CAMERA + depends on ARCH_MX1 SOC_CAMERA select FIQ select VIDEOBUF_DMA_CONTIG select MX1_VIDEO @@ -901,7 +901,7 @@ config MX3_VIDEO config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver - depends on VIDEO_DEV MX3_IPU SOC_CAMERA + depends on MX3_IPU SOC_CAMERA select VIDEOBUF_DMA_CONTIG select MX3_VIDEO ---help--- @@ -909,21 +909,21 @@ config VIDEO_MX3 config VIDEO_PXA27x tristate PXA27x Quick Capture Interface driver - depends on VIDEO_DEV PXA27x SOC_CAMERA + depends on PXA27x SOC_CAMERA select VIDEOBUF_DMA_SG ---help--- This is a v4l2 driver for the PXA27x Quick Capture Interface config VIDEO_SH_MOBILE_CEU tristate SuperH Mobile CEU Interface driver - depends on VIDEO_DEV SOC_CAMERA HAS_DMA HAVE_CLK + depends on SOC_CAMERA HAS_DMA HAVE_CLK select VIDEOBUF_DMA_CONTIG ---help--- This is a v4l2 driver for the SuperH Mobile CEU Interface config VIDEO_OMAP2 tristate OMAP2 Camera Capture Interface driver - depends on VIDEO_DEV ARCH_OMAP2 + depends on ARCH_OMAP2 select VIDEOBUF_DMA_SG ---help--- This is a v4l2 driver for the TI OMAP2 camera capture interface _ -- 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/7] drivers/media/video/pms.c needs version.h
From: Andrew Morton a...@linux-foundation.org i386 allmodconfig: drivers/media/video/pms.c: In function 'pms_querycap': drivers/media/video/pms.c:682: error: implicit declaration of function 'KERNEL_VERSION' Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/video/pms.c |1 + 1 file changed, 1 insertion(+) diff -puN drivers/media/video/pms.c~drivers-media-video-pmsc-needs-versionh drivers/media/video/pms.c --- a/drivers/media/video/pms.c~drivers-media-video-pmsc-needs-versionh +++ a/drivers/media/video/pms.c @@ -24,6 +24,7 @@ #include linux/delay.h #include linux/errno.h #include linux/fs.h +#include linux/version.h #include linux/kernel.h #include linux/slab.h #include linux/mm.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 5/7] drivers/media/video/cx18/cx18-alsa-pcm.c: fix printk warning
From: Andrew Morton a...@linux-foundation.org drivers/media/video/cx18/cx18-alsa-pcm.c: In function 'cx18_alsa_announce_pcm_data': drivers/media/video/cx18/cx18-alsa-pcm.c:82: warning: format '%d' expects type 'int', but argument 5 has type 'size_t' Cc: Andy Walls awa...@radix.net Cc: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/video/cx18/cx18-alsa-pcm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/media/video/cx18/cx18-alsa-pcm.c~drivers-media-video-cx18-cx18-alsa-pcmc-fix-printk-warning drivers/media/video/cx18/cx18-alsa-pcm.c --- a/drivers/media/video/cx18/cx18-alsa-pcm.c~drivers-media-video-cx18-cx18-alsa-pcmc-fix-printk-warning +++ a/drivers/media/video/cx18/cx18-alsa-pcm.c @@ -79,7 +79,7 @@ void cx18_alsa_announce_pcm_data(struct int period_elapsed = 0; int length; - dprintk(cx18 alsa announce ptr=%p data=%p num_bytes=%d\n, cxsc, + dprintk(cx18 alsa announce ptr=%p data=%p num_bytes=%zd\n, cxsc, pcm_data, num_bytes); substream = cxsc-capture_pcm_substream; _ -- 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 4/7] radio: add support for SAA7706H Car Radio DSP
From: Richard Röjfors richard.rojf...@pelagicore.com Initial support for the SAA7706H Car Radio DSP. It is a I2C device and currently the mute control is supported. When the device is unmuted it is brought out of reset and initiated using the proposed intialisation sequence. When muted the DSP is brought into reset state. [a...@linux-foundation.org: include delay.h] Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Douglas Schilling Landgraf dougsl...@gmail.com Cc: Hans Verkuil hverk...@xs4all.nl Cc: Randy Dunlap randy.dun...@oracle.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/radio/Kconfig | 12 drivers/media/radio/Makefile|1 drivers/media/radio/saa7706h.c | 451 ++ include/media/v4l2-chip-ident.h |3 4 files changed, 467 insertions(+) diff -puN drivers/media/radio/Kconfig~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh drivers/media/radio/Kconfig --- a/drivers/media/radio/Kconfig~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh +++ a/drivers/media/radio/Kconfig @@ -417,6 +417,18 @@ config RADIO_TEA5764_XTAL Say Y here if TEA5764 have a 32768 Hz crystal in circuit, say N here if TEA5764 reference frequency is connected in FREQIN. +config RADIO_SAA7706H + tristate SAA7706H Car Radio DSP + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want to use the SAA7706H Car radio Digital + Signal Processor, found for instance on the Russellville development + board. On the russellville the device is connected to internal + timberdale I2C bus. + + To compile this driver as a module, choose M here: the + module will be called SAA7706H. + config RADIO_TEF6862 tristate TEF6862 Car Radio Enhanced Selectivity Tuner depends on I2C VIDEO_V4L2 diff -puN drivers/media/radio/Makefile~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh drivers/media/radio/Makefile --- a/drivers/media/radio/Makefile~radio-add-the-saa7706h-car-radio-dsp-to-v4l2-chip-identh +++ a/drivers/media/radio/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_RADIO_SI470X) += si470x/ obj-$(CONFIG_USB_MR800) += radio-mr800.o obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o +obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o EXTRA_CFLAGS += -Isound diff -puN /dev/null drivers/media/radio/saa7706h.c --- /dev/null +++ a/drivers/media/radio/saa7706h.c @@ -0,0 +1,451 @@ +/* + * saa7706.c Philips SAA7706H Car Radio DSP driver + * Copyright (c) 2009 Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/module.h +#include linux/init.h +#include linux/delay.h +#include linux/errno.h +#include linux/kernel.h +#include linux/interrupt.h +#include linux/i2c.h +#include media/v4l2-device.h +#include media/v4l2-chip-ident.h + +#define DRIVER_NAME saa7706h + +/* the I2C memory map looks like this + + $1C00 - $ Not Used + $2200 - $3FFF Reserved YRAM (DSP2) space + $2000 - $21FF YRAM (DSP2) + $1FF0 - $1FFF Hardware Registers + $1280 - $1FEF Reserved XRAM (DSP2) space + $1000 - $127F XRAM (DSP2) + $0FFFDSP CONTROL + $0A00 - $0FFE Reserved + $0980 - $09FF Reserved YRAM (DSP1) space + $0800 - $097F YRAM (DSP1) + $0200 - $07FF Not Used + $0180 - $01FF Reserved XRAM (DSP1) space + $ - $017F XRAM (DSP1) +*/ + +#define SAA7706H_REG_CTRL 0x0fff +#define SAA7706H_CTRL_BYP_PLL 0x0001 +#define SAA7706H_CTRL_PLL_DIV_MASK 0x003e +#define SAA7706H_CTRL_PLL3_62975MHZ0x003e +#define SAA7706H_CTRL_DSP_TURBO0x0040 +#define SAA7706H_CTRL_PC_RESET_DSP10x0080 +#define SAA7706H_CTRL_PC_RESET_DSP20x0100 +#define SAA7706H_CTRL_DSP1_ROM_EN_MASK 0x0600 +#define SAA7706H_CTRL_DSP1_FUNC_PROM 0x +#define SAA7706H_CTRL_DSP2_ROM_EN_MASK 0x1800 +#define SAA7706H_CTRL_DSP2_FUNC_PROM 0x +#define SAA7706H_CTRL_DIG_SIL_INTERPOL 0x8000 + +#define SAA7706H_REG_EVALUATION0x1ff0 +#define SAA7706H_EVAL_DISABLE_CHARGE_PUMP 0x01 +#define SAA7706H_EVAL_DCS_CLOCK0x02 +#define SAA7706H_EVAL_GNDRC1_ENABLE
[patch 7/7] drivers/media/dvb/frontends/stv090x.c: fix use-uninitlalised
From: Andrew Morton a...@linux-foundation.org Mad guess. Cc: Manu Abraham m...@linuxtv.org Cc: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/dvb/frontends/stv090x.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitlalised drivers/media/dvb/frontends/stv090x.c --- a/drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitlalised +++ a/drivers/media/dvb/frontends/stv090x.c @@ -2047,7 +2047,7 @@ static int stv090x_chk_tmg(struct stv090 u32 reg; s32 tmg_cpt = 0, i; u8 freq, tmg_thh, tmg_thl; - int tmg_lock; + int tmg_lock = 0; freq = STV090x_READ_DEMOD(state, CARFREQ); tmg_thh = STV090x_READ_DEMOD(state, TMGTHRISE); _ -- 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 7/7] drivers/media/dvb/frontends/stv090x.c: fix use-uninitlalised
Hi Andrew, On Wed, Feb 3, 2010 at 2:40 AM, a...@linux-foundation.org wrote: From: Andrew Morton a...@linux-foundation.org Mad guess. Cc: Manu Abraham m...@linuxtv.org Cc: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/dvb/frontends/stv090x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitlalised drivers/media/dvb/frontends/stv090x.c --- a/drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitlalised +++ a/drivers/media/dvb/frontends/stv090x.c @@ -2047,7 +2047,7 @@ static int stv090x_chk_tmg(struct stv090 u32 reg; s32 tmg_cpt = 0, i; u8 freq, tmg_thh, tmg_thl; - int tmg_lock; + int tmg_lock = 0; freq = STV090x_READ_DEMOD(state, CARFREQ); tmg_thh = STV090x_READ_DEMOD(state, TMGTHRISE); _ Looks good Reviewed-by: Manu Abraham m...@linuxtv.org Acked-by: Manu Abraham m...@linuxtv.org Thanks, Manu -- 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
Any saa711x users out there?
Hello all, I am doing some quality improvements for a couple of the em28xx/saa7113 designs, and I found a pretty serious problem which appears to have been there for some time. In fact, the regression was introduced when the saa7115 support was added in 2005 (hg revision 2750). This change resulted in the anti-alias filtering being disabled by default for the saa7113 (the saa7115_init_misc block clears bit 7 of register 0x02). Without this change, vertical lines appear in the chroma on a fixed interval. The big issue is that the driver is shared with other saa7113 products, as well as products that have the saa7111, saa7114, and saa7115. So I have to figure out whether to just force on the AA filter for the saa7113, or whether it should be enabled for the others, or whether I can even turn it on for saa7113 in general or need to hack something in there to only do it for the two or three products I am testing with. So here's where I could use some help: If you have a product that uses one of the above chips, please speak up. I will be setting up a test tree where people can try out the change and see if it makes their situation better, worse, or no change. 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: [patch 6/7] drivers/media/dvb/frontends/stv090x.c: fix use-uninitialised
On Wed, Feb 3, 2010 at 2:40 AM, a...@linux-foundation.org wrote: From: Andrew Morton a...@linux-foundation.org drivers/media/dvb/frontends/stv090x.c: In function 'stv090x_blind_search': drivers/media/dvb/frontends/stv090x.c:1967: warning: 'coarse_fail' may be used uninitialized in this function Cc: Manu Abraham m...@linuxtv.org Cc: Mauro Carvalho Chehab mche...@redhat.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/dvb/frontends/stv090x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitialised drivers/media/dvb/frontends/stv090x.c --- a/drivers/media/dvb/frontends/stv090x.c~drivers-media-dvb-frontends-stv090xc-fix-use-uninitialised +++ a/drivers/media/dvb/frontends/stv090x.c @@ -1964,7 +1964,8 @@ static int stv090x_blind_search(struct s u32 agc2, reg, srate_coarse; s32 cpt_fail, agc2_ovflw, i; u8 k_ref, k_max, k_min; - int coarse_fail, lock; + int coarse_fail = 0; + int lock; k_max = 110; k_min = 10; _ Looks good Reviewed-by: Manu Abraham m...@linuxtv.org Acked-by: Manu Abraham m...@linuxtv.org Thanks, Manu -- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Hi Jean, Mauro and all, Am Dienstag, den 02.02.2010, 08:54 +0100 schrieb Jean Delvare: Hi Hermann, On Tue, 02 Feb 2010 02:47:53 +0100, hermann pitton wrote: Hi Jean, Am Montag, den 01.02.2010, 10:56 +0100 schrieb Jean Delvare: Hi Hermann, On Mon, 01 Feb 2010 02:16:35 +0100, hermann pitton wrote: For now, I only faked a P7131 Dual with a broken IR receiver on a 2.6.29 with recent, you can see that gpio 0x4 doesn't go high, but your patch should enable the remote on that P7131 analog only. I'm not sure why you had to fake anything? What I'd like to know is simply if my first patch had any negative effect on other cards. because I simply don't have that Asus My Cinema analog only in question. To recap, you previously announced a patch, tested by Daro, claiming to get the remote up under auto detection for that device and I told you having some doubts on it. My first patch was not actually tested by Daro. What he tested was loading the driver with card=146. At first I thought it was equivalent, but since then I have realized it wasn't. That's the reason why the Tested-by: was turned into a mere Cc: on my second and third patches. Mauro prefers to have a fix for that single card in need for now. Since nobody else cares, For now, see above, I can confirm that your last patch for that single device should work to get IR up with auto detection in delay after we change the card such late with eeprom detection. The meaning of that byte in use here is unknown to me, we should avoid such as much we can! It can turn out to be only some pseudo service. If your call for testers on your previous attempt, really reaches some for some reason, I'm with you, but for now I have to keep the car operable within all such snow. That I understand. What I don't understand is: if you have a SAA7134-based card, why don't you test my second patch (the one moving the call to saa7134_input_init1 to saa7134_hwinit2) on it, without faking anything? This would be a first, useful data point. sorry, the snow fall did not stop and we will need trucks next day to get it out of town. No place left. I did not reread any single line of code until now, but told you that Roman has tested a equivalent patch on his P7131_ANALOG already and I can confirm that it also had no side effects on a FlyVideo3000 card=2. For now, I would at least need some time to see, if input_init can be decoupled from all other hardware init, what you seem to suggest, and looking closer to Mauro's concerns. Thought you are asking for some test with a i2c remote next to confirm your analysis there. No such card in any machine currently, but can be done. Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: check minimum border of control
Hi Márton, On Tuesday 26 January 2010 22:37:52 Németh Márton wrote: Check also the minimum border of a value before setting it to a control value. See also http://bugzilla.kernel.org/show_bug.cgi?id=12824 . Signed-off-by: Márton Németh nm...@freemail.hu I've updated the previous patch in the uvcvideo git repository, could you please test it ? -- Regards, Laurent Pinchart -- 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] Video : pwc : Fix regression in pwc_set_shutter_speed caused by bad constant = sizeof conversion.
On Saturday 30 January 2010 17:26:51 Martin Fuzzey wrote:
Regression was caused by my commit 6b35ca0d3d586b8ecb8396821af21186e20afaf0
which determined message size using sizeof rather than hardcoded constants.
Unfortunately pwc_set_shutter_speed reuses a 2 byte buffer for a one byte
message too so the sizeof was bogus in this case.
All other uses of sizeof checked and are ok.
Signed-off-by: Martin Fuzzey mfuz...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/pwc/pwc-ctrl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/pwc/pwc-ctrl.c
b/drivers/media/video/pwc/pwc-ctrl.c index 50b415e..f7f7e04 100644
--- a/drivers/media/video/pwc/pwc-ctrl.c
+++ b/drivers/media/video/pwc/pwc-ctrl.c
@@ -753,7 +753,7 @@ int pwc_set_shutter_speed(struct pwc_device *pdev, int
mode, int value) buf[0] = 0xff; /* fixed */
ret = send_control_msg(pdev,
- SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, sizeof(buf));
+ SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, 1);
if (!mode ret = 0) {
if (value 0)
--
Regards,
Laurent Pinchart
--
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: Any saa711x users out there?
Devin Heitmueller wrote: Hello all, I am doing some quality improvements for a couple of the em28xx/saa7113 designs, and I found a pretty serious problem which appears to have been there for some time. In fact, the regression was introduced when the saa7115 support was added in 2005 (hg revision 2750). This change resulted in the anti-alias filtering being disabled by default for the saa7113 (the saa7115_init_misc block clears bit 7 of register 0x02). Without this change, vertical lines appear in the chroma on a fixed interval. The big issue is that the driver is shared with other saa7113 products, as well as products that have the saa7111, saa7114, and saa7115. So I have to figure out whether to just force on the AA filter for the saa7113, or whether it should be enabled for the others, or whether I can even turn it on for saa7113 in general or need to hack something in there to only do it for the two or three products I am testing with. So here's where I could use some help: If you have a product that uses one of the above chips, please speak up. I will be setting up a test tree where people can try out the change and see if it makes their situation better, worse, or no change. The better is to allow enabling/disabling the anti-alias via ctrl. Whatever default is chosen, the driver may adjust the control default at the board initialization, or even blocking the control when the other mode of operation is broken. I have here a few devices with saa7113 and saa7114. I think I have also one device with saa7111, but I need to check. If I'm right, it will take some time for me to prepare the saa7111 environment. The saa7113/7114 devices are easier to setup, as they are usb. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Videotext application crashes the kernel due to DVB-demux patch
Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563492] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb1/1-0:1.0/uevent Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563589] Process alevt (pid: 1780, ti=e7934000 task=e7915be0 task.ti=e7934000) Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563592] Stack: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563622] Call Trace: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8 e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b 46 04 8d 48 f8 8b 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89 50 04 89 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563697] EIP: [f8cec1b2] dvb_demux_release+0x43/0x183 [dvb_core] SS:ESP 0068:e7935f58 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563706] CR2: I don't have a 32 bti machine set up to compile the module and compare the disassembly directly. However, the kernel code above disassembles to this, and is supposedly in dvb_demux_release() but things have been inlined by the compiler: 1c: 8d 56 78lea0x78(%esi),%edx 1f: 89 54 24 04 mov%edx,0x4(%esp) 23: 89 d0 mov%edx,%eax 25: e8 e4 da 4c c8 call 0xc84cdb0e 2a: 89 f0 mov%esi,%eax 2c: e8 31 ff ff ff call 0xff62 (dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here %esi holds dmxdevfilter) 31: 83 7e 4c 01 cmpl $0x1,0x4c(%esi)if (dmxdevfilter-state DMXDEV_STATE_SET) 35: 76 73 jbe0xaa return 0; 37: 83 7e 48 02 cmpl $0x2,0x48(%esi)if (dmxdevfilter-type == DMXDEV_TYPE_PES) 3b: 75 49 jne0x86 (dvb_dmxdev_delete_pids() appears to be inlined starting here %esi still holds dmxdevfilter) 3d: 8b 46 04mov0x4(%esi),%eax %eax gets loaded with dmxdevfilter-feed.ts for list_for_each_entry_safe(feed, tmp, dmxdevfilter-feed.ts, ... 40: 8d 48 f8lea-0x8(%eax),%ecx%ecx is feed and gets loaded with the next struct dmxdev_feed pointed to by the dmxdevfilter-feed.ts list 43: 8b 41 08mov0x8(%ecx),%eax Oops appears to happen here: %ecx and hence feed was (craftily?) set to 0xfff8 based on CR2 above 46: 8d 58 f8lea-0x8(%eax),%ebx 49: 8d 7e 04lea0x4(%esi),%edi 4c: eb 28 jmp0x76 4e: 8b 41 08mov0x8(%ecx),%eax 51: 8b 51 0cmov0xc(%ecx),%edx 54: 89 50 04mov%edx,0x4(%eax) So there is something wrong with the list manipulations or, if needed, locking around the the list manipulations of the list that was introduced in the patch you identified as the problem. That is what is causing the Ooops on close(). It will take a some more scrutiny to see what exactly is wrong. With further thought, a very likely of a list's next pointer being NULL would be either: 1. Failing to init
Re: [PATCH v2 00/10] add linux driver for chip TLG2300
I'm assuming that you're referring to the analog part, right?
right.
The country code only effects the Analog TV and radio, it has no
effect on DVB-T.
Instead of a country code, the driver should use the V4L2_STD_ macros to
If we are in the radio mode, I do not have any video standard, how can I
choose
the right audio setting in this situation?
determine the audio standard. Please take a look at saa7134-tvaudio code. It has
an interesting logic to associate the V4L2_STD with the corresponding audio
settings:
For example, the audio carrier frequency and the audio standard are at tvaudio
array:
tatic struct saa7134_tvaudio tvaudio[] = {
--
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 v2 00/10] add linux driver for chip TLG2300
Huang Shijie wrote: I'm assuming that you're referring to the analog part, right? right. The country code only effects the Analog TV and radio, it has no effect on DVB-T. Instead of a country code, the driver should use the V4L2_STD_ macros to If we are in the radio mode, I do not have any video standard, how can I choose the right audio setting in this situation? In the case of radio, the frequency ranges are controlled via the tuner ioctls. There's no standard way to control the preemphasis, but I recommend adding a ctrl to select between 50us/75us and no preemphasis. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, On Fri, 29 Jan 2010, Hans Verkuil wrote: (resent: forgot to mail it to the linux-media list) Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: remove stray unlock_kernel This is a high-prio bugfix that must go to 2.6.33! Dmitri, this patch will fix the kernel oops in your latest stack trace. Just to remind you: When will this regression fix be merged? It is important that this is sent upstream for 2.6.33! Regards, Hans Thanks, Hans diffstat: saa7134-empress.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/7] drivers/media/video/Kconfig: add VIDEO_DEV dependency as needed in drivers/media/video/Kconfig
a...@linux-foundation.org wrote: From: Mike Pagano mpag...@gentoo.org Add VIDEO_DEV as dependency of VIDEO_CAPTURE_DRIVERS and all of the devices listed under this setting. Signed-off-by: Mike Pagano mpag...@gentoo.org Cc: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/video/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff -puN drivers/media/video/Kconfig~drivers-media-video-kconfig-add-video_dev-dependency-as-needed-in-drivers-media-video-kconfig drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig~drivers-media-video-kconfig-add-video_dev-dependency-as-needed-in-drivers-media-video-kconfig +++ a/drivers/media/video/Kconfig @@ -51,14 +51,14 @@ config VIDEO_TUNER menuconfig VIDEO_CAPTURE_DRIVERS bool Video capture adapters - depends on VIDEO_V4L2 + depends on VIDEO_V4L2 VIDEO_DEV VIDEO_V4L2 is defined as: config VIDEO_V4L2_COMMON tristate depends on (I2C || I2C=n) VIDEO_DEV default (I2C || I2C=n) VIDEO_DEV config VIDEO_V4L2 tristate depends on VIDEO_DEV VIDEO_V4L2_COMMON default VIDEO_DEV VIDEO_V4L2_COMMON As VIDEO_V4L2 already depends on VIDEO_DEV, there's no need to add VIDEO_DEV for VIDEO_CAPTURE_DRIVERS. default y ---help--- Say Y here to enable selecting the video adapters for webcams, analog TV, and hybrid analog/digital TV. Some of those devices also supports FM radio. -if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 +if VIDEO_DEV VIDEO_CAPTURE_DRIVERS VIDEO_V4L2 Idem. config VIDEO_ADV_DEBUG bool Enable advanced debug functionality @@ -500,7 +500,7 @@ endmenu # encoder / decoder chips config DISPLAY_DAVINCI_DM646X_EVM tristate DM646x EVM Video Display - depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + depends on MACH_DAVINCI_DM6467_EVM select VIDEOBUF_DMA_CONTIG select VIDEO_DAVINCI_VPIF select VIDEO_ADV7343 @@ -513,7 +513,7 @@ config DISPLAY_DAVINCI_DM646X_EVM config CAPTURE_DAVINCI_DM646X_EVM tristate DM646x EVM Video Capture - depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + depends on MACH_DAVINCI_DM6467_EVM select VIDEOBUF_DMA_CONTIG select VIDEO_DAVINCI_VPIF help @@ -533,7 +533,7 @@ config VIDEO_DAVINCI_VPIF config VIDEO_VIVI tristate Virtual Video Driver - depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 + depends on VIDEO_V4L2 !SPARC32 !SPARC64 select VIDEOBUF_VMALLOC default n ---help--- @@ -889,7 +889,7 @@ config MX1_VIDEO config VIDEO_MX1 tristate i.MX1/i.MXL CMOS Sensor Interface driver - depends on VIDEO_DEV ARCH_MX1 SOC_CAMERA + depends on ARCH_MX1 SOC_CAMERA select FIQ select VIDEOBUF_DMA_CONTIG select MX1_VIDEO @@ -901,7 +901,7 @@ config MX3_VIDEO config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver - depends on VIDEO_DEV MX3_IPU SOC_CAMERA + depends on MX3_IPU SOC_CAMERA select VIDEOBUF_DMA_CONTIG select MX3_VIDEO ---help--- @@ -909,21 +909,21 @@ config VIDEO_MX3 config VIDEO_PXA27x tristate PXA27x Quick Capture Interface driver - depends on VIDEO_DEV PXA27x SOC_CAMERA + depends on PXA27x SOC_CAMERA select VIDEOBUF_DMA_SG ---help--- This is a v4l2 driver for the PXA27x Quick Capture Interface config VIDEO_SH_MOBILE_CEU tristate SuperH Mobile CEU Interface driver - depends on VIDEO_DEV SOC_CAMERA HAS_DMA HAVE_CLK + depends on SOC_CAMERA HAS_DMA HAVE_CLK select VIDEOBUF_DMA_CONTIG ---help--- This is a v4l2 driver for the SuperH Mobile CEU Interface config VIDEO_OMAP2 tristate OMAP2 Camera Capture Interface driver - depends on VIDEO_DEV ARCH_OMAP2 + depends on ARCH_OMAP2 select VIDEOBUF_DMA_SG ---help--- This is a v4l2 driver for the TI OMAP2 camera capture interface I suspect that it is needed to keep at least some of the above dependencies, since VIDEO_DEV is tristate. Otherwise, someone may do things like selecting VIDEO_DEV=m, and select DISPLAY_DAVINCI_DM646X_EVM=y. Yet, your proposed patch ringed the bells. Extra care should be taken with drivers that depend on VIDEO_DEV instead of VIDEO_V4L2, due to the driver I2C dependencies. If I2C=m and VIDEO_DEV=y, and the driver has any call to an i2c core code, the driver should not be allowed to be compiled builtin. So, if one of the above drivers that depend on VIDEO_DEV has access to i2c, it should depend, instead, of VIDEO_V4L2 (where the I2C particular case were already addressed). I suspect that this is the case for soc_camera. So, the above dependencies should be, instead, VIDEO_V4L2. I'm not sure if all those DaVinci/OMAP drivers require i2c. Guennadi/Murali,
