Re: dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Hi Jarod, Thanks for the review. My answers are inlined. Jarod Wilson wrote: On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote: ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation code has a bug that incorrectly treats ULE SNDU packed into the remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer field on the subsequent MPEG2-TS frame. This patch was generated and tested against v2.6.34-rc6. I suspect that this bug was introduced in kernel version 2.6.15, but had not verified it. Care has been taken not to introduce more bug by fixing this bug, but please scrutinize the code because I always produces buggy code. Signed-off-by: Ang Way Chuang --- diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 441c064..35a4afb 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) "field: %u.\n", priv->ts_count, *from_where); /* Drop partly decoded SNDU, reset state, resync on PUSI. */ - if (priv->ule_skb) { - dev_kfree_skb( priv->ule_skb ); + if (priv->ule_skb || priv->ule_sndu_remain) { + if (priv->ule_skb) + dev_kfree_skb( priv->ule_skb ); dev->stats.rx_errors++; dev->stats.rx_frame_errors++; } That code block looks odd that way, but after staring at it for a minute, it makes sense. Another way to do it that might read cleaner (and reduce excessive tab indent levels) would be to add a 'bool errors', then: bool errors = false; ... if (priv->ule_skb) { errors = true; dev_kfree_skb(priv->ule_skb); } if (errors || priv->ule_sndu_remain) { dev->stats.rx_errors++; dev->stats.rx_frame_errors++; } Yeap, I'm a lazy person. @@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 *buf, size_t buf_len ) from_where += 2; } + priv->ule_sndu_remain = priv->ule_sndu_len + 2; /* * State of current TS: * ts_remain (remaining bytes in the current TS cell) Is this *always* true? Your description says "...the remaining 2 or 3 bytes", indicating this could sometimes need to be +3. Is +0 also a possibility? Not sure whether I understand your question correctly. Here is my attempt to answer your question. The encapsulation format always mandate that at least of 2 bytes of ULE SNDU (the LENGTH field) must be present within a MPEG2-TS frame. So, if only 1 byte of the ULE SNDU get packed into the remaining MPEG2-TS frame, then it is invalid. Of course, there is no issue regarding 0 byte as that would be the case of filling MPEG2-TS frame up to its boundary. New ULE SNDU will have to packed into the next MPEG2-TS frame in that case. Now the problem with existing code is the interpretation of remainder length when 2 or 3 bytes of ULE SNDU are packed into the remainder of MPEG2-TS frame. In the 2 bytes case, only the LENGTH field is available while in the case 3 bytes, only the 1st octet of the 2-octets TYPE field and the LENGTH field are available. The ule_sndu_remain should carry the value of length of ULE SNDU following the the TYPE field. Technically, this would mean that remainder byte of ULE SNDU that need to be received is going to be: Value(LENGTH) + 2 (We owe 2 bytes of TYPE field here) if only 2 bytes of ULE SNDU is packed (as in the case of case 0: at line 550). This is addressed by adding the priv->ule_sndu_remain = priv->ule_sndu_len + 2; Value(LENGTH) + 1 (We owe 1 byte of TYPE field here) if 3 bytes of ULE SNDU is packed (as in the case of case 1: at 545). This is addressed by adding priv->ule_sndu_remain--; If complete ULE header (>= 4 bytes) is available: priv->ule_sndu_remain = priv->ule_sndu_len; at line 582 takes care of the rest and it works just fine in the existing code. Due to the wrong interpretation of remaining length of ULE SNDU when 2 or 3 bytes of ULE SNDU are packed into a MPEG2-TS frame, the subsequent checking of payload pointer (line 455) always fails leading to unnecessary packet drops. Looking back at the fix after a few months, I had trouble understanding how these few lines fixed the problem at first glance. @
Hardware able to reliably tune to high rate DVB-S2
Hi all, I am looking for a DVB-S/S2 card able to reliably tune to high symbol rates DVB-S2 (here I have a transponder with 45MS/s), I also need this with CI support. I have seen that mystix cards could be a good candidate but I am not sure. PCI or PCIe is OK, dual tuner is not mandatory. TIA, Bye 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
Loosing connection on hauppauge hdvpr (fixed firmware)
Hello, I got a problem with my Hauppauge hdpvr device: After getting an involuntary firmware update of my cable-tv box (UPC Austria), the hdvpr device looses connection when a commercial appears or when the channel will be changed. They have installed a commercial-marker or other stupid thing. The hdpvr-configuration is YPbPr-analog-input and S/PDIF/toslink-digital-input. I am using the HD Fury 2-device to get the HDMI-source from the cable box. This might be the problem device and the Fury maybe cut off the connection for short time - but it isn't visible by me. Anyway, the firmware should be able to CATCH such connection-abort-problems? Plugging the HDMI-source to the TV directly will not show any problems. There are no information in the log (hdpvr debug setting is highest: 7) There is another phenomenon with the digital sound: Plugging the toslink cable from tv-box to the hdpvr device will interrupt the sound for 1-2 seconds after 5 seconds repeatedly. I'dont know if this problem is part of the kernel module but it would be nice if this could be fixed. I'm available for some testing and try-out-sessions to find out more.. Best Rene -- 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 -mmotm] media: ak881x needs slab.h
From: Randy Dunlap Add slab.h to fix ak881x build: drivers/media/video/ak881x.c:265:error: implicit declaration of function 'kzalloc' drivers/media/video/ak881x.c:265:warning: assignment makes pointer from integer without a cast drivers/media/video/ak881x.c:283:error: implicit declaration of function 'kfree' Signed-off-by: Randy Dunlap Cc: Guennadi Liakhovetski Cc: Mauro Carvalho Chehab --- drivers/media/video/ak881x.c |1 + 1 file changed, 1 insertion(+) --- mmotm-2010-0519-1612.orig/drivers/media/video/ak881x.c +++ mmotm-2010-0519-1612/drivers/media/video/ak881x.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include -- 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
MMAP buffer allocation Davinci
Karicheri, Muralidharan ti.com> writes: > > Asheesh, > > Please re-send this patch with following:- > > 1) A detailed description of what you are trying to fix in each of this patch. You need to also run the > checkpatch.pl script to make sure there are no errors. > 2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming > you have based it upon the Arago tree. > 3) add the Signed-off-by field. > > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 > phone: 301-407-9583 > email: m-karicheri2 ti.com > > >-Original Message- > >From: linux-media-owner vger.kernel.org [mailto:linux-media- > >owner vger.kernel.org] On Behalf Of Bhardwaj, Asheesh > >Sent: Wednesday, May 19, 2010 12:45 PM > >To: linux-media vger.kernel.org > >Subject: > > > >The patches will be applied to the davinci tree > >the ../drivers/media/video/davinci and will affect the both the capture and > >display drivers. Apply these patches to the git kernel. > >From asheeshb ti.com # This line is ignored. > >GIT: > >From: asheeshb ti.com > >Subject: > >In-Reply-To: > > > >-- > >To unsubscribe from this list: send the line "unsubscribe linux-media" in > >the body of a message to majordomo vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > The following portion of the mail was truncted from the originla post. Thers are 1-7 patches on this series. The kernel patches are targetted for support of memory allocation during boot time for large buffers. This will allow the user to get contiguous buffers beyond linux memory and can configure the location and size of the buffer using parametrs configured during boot time using bootargs. The current implementation will allow the application to get MMAP buffers but those buffers cannot be contiguous and create defragmentation. The approach to provide contiguous buffers is inherited from the ../drivers/media/video/sh_mobile_ceu_camera.c already exist in the community code which uses dma_alloc_coherent function to get the contiguous buffers from the memory. During runtime the driver will allocate the required buffers from the contiguous memory. The memory can be configured using the following arguments on the bootargs 1. Davinci display and vpfe cature driver davinci_display.cont2_bufsize= davinci_display.cont2_bufoffset= vpfe_capture.cont_bufsize== vpfe_capture.cont_bufoffset== 2. DavinciHD VPIF display and capture driver vpif_display.cont_bufsize= vpif_display.cont_bufoffset= vpif_capture.cont_bufsize= vpif_capture.cont_bufoffset= The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel. -- 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 2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
On Thursday 06 May 2010 06:06:21, Mauro Carvalho Chehab wrote: > Hi Arnout, > > Arnout Vandecappelle wrote: > > videobuf_dma_init_user_locked() uses get_user_pages() to get the > > virtual-to-physical address mapping for user-allocated memory. > > However, the user-allocated memory may be non-pageable because it > > is an I/O range or similar. get_user_pages() fails with -EFAULT > > in that case. > > > > If the user-allocated memory is physically contiguous, the approach > > of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still > > returned. > > --- > > > > drivers/media/video/videobuf-dma-sg.c | 18 ++ > > 1 files changed, 18 insertions(+), 0 deletions(-) > > Your patch looked sane to my eyes. I just noticed one warning at the > dprintk, when compiled with 32 bits address space, and a few coding > style issues. I needed to rebase it also, due to some changes at > videobuf. > > However, you missed your SOB. Could you please send it? I'm enclosing > the version with my changes for you to sign. > > --- > > V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory > Date: Wed, 17 Mar 2010 22:53:05 - > From: Arnout Vandecappelle > > videobuf_dma_init_user_locked() uses get_user_pages() to get the > virtual-to-physical address mapping for user-allocated memory. > However, the user-allocated memory may be non-pageable because it > is an I/O range or similar. get_user_pages() fails with -EFAULT > in that case. > > If the user-allocated memory is physically contiguous, the approach > of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still > returned. > > [mche...@redhat.com: Fixed CodingStyle and warning at dprintk on i386] > > --- > drivers/media/video/videobuf-dma-sg.c | 18 ++ > drivers/media/video/videobuf-dma-sg.c | 20 > 1 file changed, 20 insertions(+) > > --- work.orig/drivers/media/video/videobuf-dma-sg.c > +++ work/drivers/media/video/videobuf-dma-sg.c > @@ -145,6 +145,7 @@ static int videobuf_dma_init_user_locked > { > unsigned long first, last; > int err, rw = 0; > + struct vm_area_struct *vma; > > dma->direction = direction; > switch (dma->direction) { > @@ -162,6 +163,25 @@ static int videobuf_dma_init_user_locked > last = ((data+size-1) & PAGE_MASK) >> PAGE_SHIFT; > dma->offset = data & ~PAGE_MASK; > dma->nr_pages = last-first+1; > + > + /* In case the buffer is user-allocated and is actually an IO buffer > for +some other hardware, we cannot map pages for it. It in fact > behaves +the same as an overlay. */ > + vma = find_vma(current->mm, data); > + if (vma && (vma->vm_flags & VM_IO)) { > + /* Only a single contiguous buffer is supported. */ > + if (vma->vm_end < data + size) { > + dprintk(1, "init user: non-contiguous IO buffer.\n"); > + /* same error that get_user_pages() would give */ > + return -EFAULT; > + } > + dma->bus_addr = (vma->vm_pgoff << PAGE_SHIFT) + > + (data - vma->vm_start); > + dprintk(1, "init user IO [0x%lx+0x%lx => %d pages at 0x%llx]\n", > + data, size, dma->nr_pages, (long long)dma->bus_addr); > + return 0; > + } > + > dma->pages = kmalloc(dma->nr_pages * sizeof(struct page *), > GFP_KERNEL); if (NULL == dma->pages) > return -ENOMEM; Signed-off-by: Arnout Vandecappelle -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, BelgiumBE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43 -- 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-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote: > ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation > code has a bug that incorrectly treats ULE SNDU packed into the > remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer > field on the subsequent MPEG2-TS frame. > > This patch was generated and tested against v2.6.34-rc6. I suspect > that this bug was introduced in kernel version 2.6.15, but had not > verified it. > > Care has been taken not to introduce more bug by fixing this bug, but > please scrutinize the code because I always produces buggy code. > > Signed-off-by: Ang Way Chuang > > --- > > diff --git a/drivers/media/dvb/dvb-core/dvb_net.c > b/drivers/media/dvb/dvb-core/dvb_net.c > index 441c064..35a4afb 100644 > --- a/drivers/media/dvb/dvb-core/dvb_net.c > +++ b/drivers/media/dvb/dvb-core/dvb_net.c > @@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8 > *buf, size_t buf_len ) > "field: %u.\n", > priv->ts_count, *from_where); > > /* Drop partly decoded SNDU, > reset state, resync on PUSI. */ > - if (priv->ule_skb) { > - dev_kfree_skb( > priv->ule_skb ); > + if (priv->ule_skb || > priv->ule_sndu_remain) { > + if (priv->ule_skb) > + dev_kfree_skb( > priv->ule_skb ); > dev->stats.rx_errors++; > > dev->stats.rx_frame_errors++; > } That code block looks odd that way, but after staring at it for a minute, it makes sense. Another way to do it that might read cleaner (and reduce excessive tab indent levels) would be to add a 'bool errors', then: bool errors = false; ... if (priv->ule_skb) { errors = true; dev_kfree_skb(priv->ule_skb); } if (errors || priv->ule_sndu_remain) { dev->stats.rx_errors++; dev->stats.rx_frame_errors++; } > @@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 > *buf, size_t buf_len ) > from_where += 2; > } > > + priv->ule_sndu_remain = priv->ule_sndu_len + 2; > /* >* State of current TS: >* ts_remain (remaining bytes in the current TS cell) Is this *always* true? Your description says "...the remaining 2 or 3 bytes", indicating this could sometimes need to be +3. Is +0 also a possibility? > @@ -543,6 +545,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 > *buf, size_t buf_len ) >*/ > switch (ts_remain) { > case 1: > + priv->ule_sndu_remain--; > priv->ule_sndu_type = from_where[0] << > 8; > priv->ule_sndu_type_1 = 1; /* first > byte of ule_type is set. */ > ts_remain -= 1; from_where += 1; > @@ -556,6 +559,7 @@ static void dvb_net_ule( struct net_device *dev, const u8 > *buf, size_t buf_len ) > default: /* complete ULE header is present in > current TS. */ > /* Extract ULE type field. */ > if (priv->ule_sndu_type_1) { > + priv->ule_sndu_type_1 = 0; > priv->ule_sndu_type |= > from_where[0]; > from_where += 1; /* points to > payload start. */ > ts_remain -= 1; -- Jarod Wilson ja...@redhat.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] input: fix error at the default input_get_keycode call
On Thu, 20 May 2010 01:55:50 -0300, Mauro Carvalho Chehab said: > [ 76.376140] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 76.376670] IP: [] input_default_getkeycode_from_index+0x40/0x60 > [ 76.376670] *pde = > [ 76.376670] Oops: 0002 [#1] SMP > [ 76.376670] last sysfs file: /sys/devices/virtual/block/dm-5/range > [ 76.376670] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 > ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log uinput > snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer > snd ppdev sg parport_pc soundcore k8temp snd_page_alloc forcedeth pcspkr > hwmon parport i2c_nforce2 sd_mod crc_t10dif sr_mod cdrom pata_acpi > ata_generic pata_amd sata_nv floppy nouveau ttm drm_kms_helper drm > i2c_algo_bit i2c_core dm_mod [last unloaded: scsi_wait_scan] > [ 76.376670] > [ 76.376670] Pid: 6183, comm: getkeycodes Not tainted 2.6.34 #11 C51MCP51/ > [ 76.376670] EIP: 0060:[] EFLAGS: 00210046 CPU: 0 > [ 76.376670] EIP is at input_default_getkeycode_from_index+0x40/0x60 > [ 76.376670] EAX: EBX: ECX: 0002 EDX: f53ebdc8 > [ 76.376670] ESI: f53ebdc8 EDI: f5daf794 EBP: f53ebdb8 ESP: f53ebdb4 > [ 76.376670] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 76.376670] Process getkeycodes (pid: 6183, ti=f53ea000 task=f53bd060 > task.ti=f53ea000) > [ 76.376670] Stack: > [ 76.376670] f5daf000 f53ebdec c138d233 f53ebe30 00200286 > 0004 > [ 76.376670] <0> f53ebe2c f5da0340 c16c12cc > f53ebdf8 c12f4148 > [ 76.376670] <0> c12f4130 f53ebe24 c138d9f8 0002 0001 > c138d980 c12f4130 > [ 76.376670] Call Trace: > [ 76.376670] [] ? input_get_keycode+0x73/0x90 > > input_default_getkeycode_from_index() returns the scancode at > kt_entry.scancode > pointer. Fill it with the scancode address at the function call. > > Thanks-to: Vladis Kletnieks for pointing the issue > > Cc: Dmitry Torokhov > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/input/input.c b/drivers/input/input.c > index 3b63fad..7851d8e 100644 Still dies, but in input_set_keycode() instead... [ 35.294528] BUG: unable to handle kernel NULL pointer dereference at (null) [ 35.295005] IP: [<(null)>] (null) [ 35.296935] PGD 11da3c067 PUD 11d4ad067 PMD 0 [ 35.296935] Oops: 0010 [#1] PREEMPT SMP [ 35.299667] last sysfs file: /sys/devices/pci:00/:00:1a.7/usb1/idVendor [ 35.300328] CPU 0 [ 35.300328] Modules linked in: [ 35.300328] [ 35.300328] Pid: 2481, comm: keymap Not tainted 2.6.34-mmotm0519 #1 0X564R/Latitude E6500 [ 35.300328] RIP: 0010:[<>] [<(null)>] (null) [ 35.300328] RSP: 0018:88011d4d5cb0 EFLAGS: 00010046 [ 35.310163] RAX: RBX: 88011c03e000 RCX: 0081 [ 35.310163] RDX: 88011d4d5cc4 RSI: 88011d4d5cc8 RDI: 88011c03e000 [ 35.310163] RBP: 88011d4d5d28 R08: 88011e9b28e8 R09: 0001 [ 35.310163] R10: 81e0b160 R11: 0004 R12: 00a4 [ 35.310163] R13: 88011c03e830 R14: 0286 R15: 88011d4d5cc8 [ 35.310163] FS: 7f4b86283700() GS:88000260() knlGS: [ 35.319397] CS: 0010 DS: ES: CR0: 80050033 [ 35.319397] CR2: CR3: 00011d575000 CR4: 000406f0 [ 35.319397] DR0: DR1: DR2: [ 35.319397] DR3: DR6: 0ff0 DR7: 0400 [ 35.319397] Process keymap (pid: 2481, threadinfo 88011d4d4000, task 88011e9b28c0) [ 35.319397] Stack: [ 35.319397] 813bf3d1 88011d4d5cf8 00810246 008100a4 [ 35.319397] <0> 0004 88011d4d5cc4 88011cf11200 [ 35.319397] <0> 88011c179000 88011d4d5d28 0081 7fff9ee21fa0 [ 35.319397] Call Trace: [ 35.319397] [] ? input_set_keycode+0xad/0x12c [ 35.319397] [] evdev_do_ioctl+0x22b/0x79b [ 35.337913] [] ? __mutex_lock_common+0x564/0x580 [ 35.337913] [] ? evdev_ioctl_handler+0x3d/0x80 [ 35.341507] [] ? evdev_ioctl_handler+0x3d/0x80 [ 35.341507] [] evdev_ioctl_handler+0x63/0x80 [ 35.344034] [] evdev_ioctl+0xb/0xd [ 35.344034] [] vfs_ioctl+0x2d/0xa1 [ 35.344034] [] do_vfs_ioctl+0x494/0x4cd [ 35.344034] [] sys_ioctl+0x57/0x95 [ 35.344034] [] system_call_fastpath+0x16/0x1b [ 35.344034] Code: Bad RIP value. [ 35.344034] RIP [<(null)>] (null) [ 35.344034] RSP [ 35.344034] CR2: [ 35.357018] ---[ end trace 394fa5aa8a77b6f3 ]--- pgpII4PM6eepb.pgp Description: PGP signature
RE:
Asheesh, Please re-send this patch with following:- 1) A detailed description of what you are trying to fix in each of this patch. You need to also run the checkpatch.pl script to make sure there are no errors. 2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming you have based it upon the Arago tree. 3) add the Signed-off-by field. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >ow...@vger.kernel.org] On Behalf Of Bhardwaj, Asheesh >Sent: Wednesday, May 19, 2010 12:45 PM >To: linux-media@vger.kernel.org >Subject: > >The patches will be applied to the davinci tree >the ../drivers/media/video/davinci and will affect the both the capture and >display drivers. Apply these patches to the git kernel. >From ashee...@ti.com # This line is ignored. >GIT: >From: ashee...@ti.com >Subject: >In-Reply-To: > >-- >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
[RFC] V4L2 Controls State Store/Restore File Format
Hi all, Below is a proposal for the file format to use when storing/restoring v4l2 controls state. I've some doubts concerning atomically set controls and string controls (see below) that may be inducing me on error. The format is intended to be generic enough to support any control class so I hope to receive comments for any special cases that I might have missed or overlooked. Don't worry about bashing on the proposal to hard I have a hard skin :-D Regards, Paulo -- Forwarded message -- From: Hans de Goede Date: 2010/5/20 Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format To: Paulo Assis Cc: Laurent Pinchart , martin_ru...@logitech.com Hi Paulo, Clearly you've though quite a bit about this I had not realized this would be this complex (with ordering issues etc.). This looks like a good proposal to start with to me, I think it would be good to further discuss this on the linux-media list, where other v4l devs can read it and chime in. Regards, Hans On 05/20/2010 03:11 PM, Paulo Assis wrote: > > Hans, > Below is the RFC with my proposed control state file format for > store/restore functionality. > I have several doubts, mostly regarding controls that must be set > atomically with the extended control API. > The main question is: > How does an application know that a group of controls must be set atomically ? > Is this reported by the driver or is it something that the application > must know. > > Also for string controls, I've only seen two implementations on RDS > controls, so I've set these with low precedence/priority order > compared with other control types. > > Awaiting comments, bash it all you want :-) > > Regards, > Paulo > __ > > [RFC] V4L2 Controls State Store/Restore File Format > > VERSION > > 0.0.1 > > ABSTRACT > > This document proposes a standard for the file format used by v4l2 > applications to store/restore the controls state. > This unified file format allows sharing control profiles between > applications, making it much easier on both developers and users. > > INTRODUCTION > > V4l2 controls can be divided by classes and types. > Controls in different classes are not dependent between themselves, on > the other end if two controls belong to the same class they may or may > not be dependent. > A good example are automatic controls and their absolute counterparts, > e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN. > Controls must be set following the dependency order, automatic > controls must be set first or else setting the absolute value may > fail, when that was not the intended behavior (auto disabled). > After a quick analyses of the v4l2 controls, we are left to conclude > that auto controls are in most cases of the > boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that > is of the menu type. > So ordering control priority by control type seems logical and it can > be done in the following order: > > 1-V4L2_CTRL_TYPE_BOOLEAN > 2-V4L2_CTRL_TYPE_MENU > 3-V4L2_CTRL_TYPE_INTEGER > 4-V4L2_CTRL_TYPE_INTEGER64 > 5-V4L2_CTRL_TYPE_STRING > > Button controls are stateless so they can't be stored and thus are out > of the scope of this document. > Relative controls are also in effect stateless, since they will always > depend on their current state and thus can't be stored. > > There are also groups of controls that must be set atomically, so > these need to be grouped together and properly identified when loading > the controls state from a file. > > The proposed file format takes all of this into account and tries to > make implementation of both store and restore functionality as easy as > possible. > > FILE FORMAT > > The proposed file format is a regular text file with lines terminating > with the newline character '\n'. > Comments can be inserted by adding '#' at the beginning of the line, > and can safely be ignored when parsing the file. > > FILE EXTENSION > > Although not much relevant, the file extension makes it easy to > visually identify the file type and also for applications to list > relevant files, so we propose that v4l2 control state files be > terminated by the suffix: ".v4l" > > FILE HEADER > > The file must always start with a commented line containing the file > type identification and the version of this document on which it is > based: > > #V4L2/CTRL/0.0.1 > > Additionally it may contain extra information like the application > name that generated the file and for usb devices the vid and pid of > the device to whom the controls relate in hexadecimal notation: > > APP_NAME{"application name"} > VID{0x00} > PID{0x00} > > CONTROLS DATA > > The controls related data must be ordered by control type and for each > type the ordering must be done by control ID. Ordering by control ID > will also group the controls by class. > The exception to the above rule are controls that need to be set > atomically, these must be grouped together independent of their type. > > Each control must have is data set i
Re: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134
Hi, Am Freitag, den 21.05.2010, 06:01 +1000 schrieb Nathan Metcalf: > Thanks Hermann, > Does this mean I need to apply that patch you linked to me? Then > recompile the module and re-insert? > > Regards, > Nathan depends on your source. The 2.6.32 has no support for that card and it depends also on further patches for tuner and demodulator However, all 4 patches in question are in this pull request Von: Mauro Carvalho Chehab An: Linus Torvalds Kopie: Andrew Morton , linux-ker...@vger.kernel.org, linux-media@vger.kernel.org Betreff: [GIT PULL for 2.6.33] V4L/DVB updates Datum: Wed, 9 Dec 2009 02:16:39 -0200 (05:16 CET) and via Michael Krufky and Michael Obst for the remote. (add the card, fix the entry, add the remote support, fix some coding style) You need a kernel >= 2.6.33 or have to build and install mercurial v4l-dvb from linuxtv.org on older kernels. The current v4l-dvb is in process to gain deeper compatibility for older kernels again, see the daily mails. [cron job] v4l-dvb daily build Progress was made from 2.6.33 only a few days ago down to 2.6.25 now. My latest test was on a 2.6.29. Else you can also use a snapshot from May 04 2010, after that backward compat was limited to 2.6.33 only for a while, see the "v4l-dvb daily build" messages. For 2.6.32 the recent is good again. Cheers, Hermann > On 20/05/10 09:28, hermann pitton wrote: > > Hi Nathan, > > > > Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf: > > > >> Hey Guys, > >> I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD > >> Tuner card working in Ubuntu (Latest) > >> When I load the saa7134_dvb kernel module, there are no errors, but > >> /dev/dvb is not created. > >> > >> I have tried enabling the debug=1 option when loading the module, but > >> don't get any more useful information. > >> > >> Can someone please assist me? Or direct me to the correct place? > >> > >> Regards, > >> Nathan Metcalf > >> > >> > > there was some buglet previously, but the card is else supported since > > Nov. 01 2009 on mercurial v4l-dvb and later kernels. > > > > http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd > > > > Support for the remote was also added. > > > > 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
AVerMedia A336 MiniCard Hybrid DVB-T
I couldn't find any information on this card or how to support it. Here is the output of lsusb -v. This card was built into the Acer Z5600 computer I bought a couple of weeks ago. Running Ubuntu 10.04 with kernel 2.6.32; I can install newer mainline kernels if required. Bus 002 Device 005: ID 07ca:1336 AVerMedia Technologies, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x07ca AVerMedia Technologies, Inc. idProduct 0x1336 bcdDevice 40.01 iManufacturer 1 AVerMedia TECHNOLOGIES, Inc. iProduct 2 AVerMedia A336 MiniCard Hybrid DVB-T iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 344 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 AVerMedia A336 MiniCard Hybrid DVB-T bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 32 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0e EP 14 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 1 bInterfaceCount 6 bFunctionClass 255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 255 Vendor Specific Protocol iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8f EP 15 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 8 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 9 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x
RE: [linux-dvb] new DVB-T initial tuning for fr-nantes
> One thing that would be good to do -- for someone who is in the > area served by a transmitter -- rather than use «AUTO» for the > FEC and Guard Interval values above, would be to perform a NIT > scan on the appropriate frequencies. > > This should give as a result the actual transmitter frequency > and other parameters in use, and perhaps related ones from other > sites. > > These values are configured by the broadcaster and are therefore > not guaranteed to be 100% accurate, but it is more likely that > they know the values they are using -- these values can be used > to locate other transmitter frequencies, as is the well-known > case for DVB-S satellite NIT tables. Unfortunately, the terrestrial delivery descriptors are completely wrong in the NIT of the French terrestrial network. The NIT is the same all over the country, which is not appropriate in a terrestrial network, and the frequency, FEC and guard interval are wrong. The same TS will have distinct frequencies (of course) on different transmitters but also distinct FEC and guard interval (actually, two combinations are used: either 2/3 & 1/32 or 3/4 & 1/8). Recently, many transmitters have changed the modulation parameters while staying on the same frequency. It is very difficult to keep up to date. Between the moment when you submit a patch with the new parameters and the moment you get the file in your distro, the parameters may have changed again. I think that in such a moving environment, the "AUTO" choice is definitely better. -Thierry N�r��yb�X��ǧv�^�){.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥
[PULL] nGene updates from http://linuxtv.org/hg/~endriss/ngene-new
Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene-new for the following 6 changesets: 01/06: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe' http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=691aeec6bdb2 02/06: ngene: Do not call demuxer with interrupts disabled http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=dfdedb2cc2d1 03/06: ngene: Implement support for MSI http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=029fc05ae78e 04/06: ngene: Make command timeout workaround configurable http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=dc8862594f67 05/06: ngene: MSI cleanup http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=26d2789d9f32 06/06: ngene: Remove debug message http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=bbabad270bf6 ngene-cards.c | 15 ++ ngene-core.c | 82 +++--- ngene-dvb.c | 14 ++--- ngene.h |3 ++ 4 files changed, 77 insertions(+), 37 deletions(-) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L/DVB: New NXP tda18218 tuner
Signed-off-by: Nikola Pajkovsky --- drivers/media/common/tuners/Kconfig |7 + drivers/media/common/tuners/Makefile|1 + drivers/media/common/tuners/tda18218.c | 432 +++ drivers/media/common/tuners/tda18218.h | 44 +++ drivers/media/common/tuners/tda18218_priv.h | 36 +++ drivers/media/dvb/dvb-usb/af9015.c | 13 +- drivers/media/dvb/frontends/af9013.c| 15 + drivers/media/dvb/frontends/af9013_priv.h |5 +- 8 files changed, 548 insertions(+), 5 deletions(-) create mode 100644 drivers/media/common/tuners/tda18218.c create mode 100644 drivers/media/common/tuners/tda18218.h create mode 100644 drivers/media/common/tuners/tda18218_priv.h diff --git a/drivers/media/common/tuners/Kconfig b/drivers/media/common/tuners/Kconfig index 409a426..b00c63c 100644 --- a/drivers/media/common/tuners/Kconfig +++ b/drivers/media/common/tuners/Kconfig @@ -179,4 +179,11 @@ config MEDIA_TUNER_MAX2165 help A driver for the silicon tuner MAX2165 from Maxim. +config MEDIA_TUNER_TDA18218 + tristate "NXP TDA18218 silicon tuner" + depends on VIDEO_MEDIA && I2C + default m if MEDIA_TUNER_CUSTOMISE + help + A driver for the silicon tuner TDA18218 from NXP. + endif # MEDIA_TUNER_CUSTOMISE diff --git a/drivers/media/common/tuners/Makefile b/drivers/media/common/tuners/Makefile index a543852..96da03d 100644 --- a/drivers/media/common/tuners/Makefile +++ b/drivers/media/common/tuners/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_MEDIA_TUNER_MXL5005S) += mxl5005s.o obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o +obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core EXTRA_CFLAGS += -Idrivers/media/dvb/frontends diff --git a/drivers/media/common/tuners/tda18218.c b/drivers/media/common/tuners/tda18218.c new file mode 100644 index 000..1860b18 --- /dev/null +++ b/drivers/media/common/tuners/tda18218.c @@ -0,0 +1,432 @@ +/* + * Driver for NXP TDA18218 silicon tuner + * + * Copyright (C) 2010 Lauris Ding + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ +#include "tda18218.h" +#include "tda18218_priv.h" + +static int tda18218_write_reg(struct dvb_frontend *fe, u8 reg, u8 val) +{ + struct tda18218_priv *priv = fe->tuner_priv; + u8 buf[2] = { reg, val }; + struct i2c_msg msg = { .addr = priv->cfg->i2c_address, .flags = 0, + .buf = buf, .len = 2 }; + int ret; + + if (fe->ops.i2c_gate_ctrl) + fe->ops.i2c_gate_ctrl(fe, 1); + /* write register */ + ret = i2c_transfer(priv->i2c, &msg, 1); + if (fe->ops.i2c_gate_ctrl) + fe->ops.i2c_gate_ctrl(fe, 0); + + if (ret != 1) + printk(KERN_WARNING "I2C write failed ret: %d reg: %02x\n", ret, reg); + + return (ret == 1 ? 0 : ret); +} + +static int tda18218_write_regs(struct dvb_frontend *fe, u8 reg, + u8 *val, u8 len) +{ + struct tda18218_priv *priv = fe->tuner_priv; + u8 buf[1+len]; + struct i2c_msg msg = { + .addr = priv->cfg->i2c_address, + .flags = 0, + .len = sizeof(buf), + .buf = buf }; + + int ret; + + buf[0] = reg; + memcpy(&buf[1], val, len); + + if (fe->ops.i2c_gate_ctrl) + fe->ops.i2c_gate_ctrl(fe, 1); + ret = i2c_transfer(priv->i2c, &msg, 1); + if (fe->ops.i2c_gate_ctrl) + fe->ops.i2c_gate_ctrl(fe, 1); + + if (ret != 1) + printk(KERN_WARNING "I2C write failed ret: %d reg: %02x len: %d\n", ret, reg, len); + + return (ret == 1 ? 0 : ret); +} + +static int tda18218_read_regs(struct dvb_frontend *fe) +{ + struct tda18218_priv *priv = fe->tuner_priv; + u8 *regs = priv->tda18218_regs; + u8 buf = 0x00; + int ret; + struct i2c_msg msg[] = { + { .addr = 0xc0, .flags = 0, + .buf = &buf, .len = 1 }, + { .addr = 0xc0, .flags = I2C_M_RD, + .buf = regs, .len = 59 } + }; + + if (fe->ops.i2c_gate_ctrl) + fe->ops.i2c_gate_ctrl(fe, 1); + + /* read al
[PATCH 06/11] V4L/DVB: omap_vout: Storage class should be before const qualifier
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser --- drivers/media/video/omap/omap_vout.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 4c0ab49..d6a2ae1 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -128,7 +128,7 @@ module_param(debug, bool, S_IRUGO); MODULE_PARM_DESC(debug, "Debug level (0-1)"); /* list of image formats supported by OMAP2 video pipelines */ -const static struct v4l2_fmtdesc omap_formats[] = { +static const struct v4l2_fmtdesc omap_formats[] = { { /* Note: V4L2 defines RGB565 as: * -- 1.6.3.3 -- 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
Credit Inquiries email lists
Here's a list package on sale this week only: Business/Consumer List Package US New Business Database - 4.8 million records all with emails American Consumer Database - 1,300,000 records all with emails. American Homeowners - 1 million Full Data Records all with emails All complete lists above: $295 There are more packages and not just for business. we also have healthcare, consumers and more. Contact me here for more info or to get samples: successto...@gmx.com To invoke no further correspondence status please send an email to remfi...@gmx.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