[PATCH 1/1] media: rc: ati_remote.c: code style and compile warning fixing
changes:
1. break some lines that are longer than 80 characters.
2. remove local function prototype declarations which do not
need.
3. replace TAB character with a space character in function
comments.
4. change the types of array init1[] and init2[] to
unsigned char to avoid compile warning.
Signed-off-by: Du, Changbin changbin...@gmail.com
---
drivers/media/rc/ati_remote.c | 139
+
1 file changed, 84 insertions(+), 55 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 7be377f..0df66ac 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -23,6 +23,8 @@
*Vincent Vanackere vanack...@lif.univ-mrs.fr
*Added support for the Lola remote contributed by:
*Seth Cohn sethc...@yahoo.com
+ * Jul 2012: Du, Changbin changbin...@gmail.com
+ *Code style and compile warning fixing
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
*
@@ -147,7 +149,8 @@ static bool mouse = true;
module_param(mouse, bool, 0444);
MODULE_PARM_DESC(mouse, Enable mouse device, default = yes);
-#define dbginfo(dev, format, arg...) do { if (debug) dev_info(dev , format
, ## arg); } while (0)
+#define dbginfo(dev, format, arg...) \
+ do { if (debug) dev_info(dev , format , ## arg); } while (0)
#undef err
#define err(format, arg...) printk(KERN_ERR format , ## arg)
@@ -191,17 +194,41 @@ static const char *get_medion_keymap(struct
usb_interface *interface)
return RC_MAP_MEDION_X10;
}
-static const struct ati_receiver_type type_ati = { .default_keymap
= RC_MAP_ATI_X10 };
-static const struct ati_receiver_type type_medion = {
.get_default_keymap = get_medion_keymap };
-static const struct ati_receiver_type type_firefly = { .default_keymap
= RC_MAP_SNAPSTREAM_FIREFLY };
+static const struct ati_receiver_type type_ati = {
+ .default_keymap = RC_MAP_ATI_X10
+};
+static const struct ati_receiver_type type_medion = {
+ .get_default_keymap = get_medion_keymap
+};
+static const struct ati_receiver_type type_firefly = {
+ .default_keymap = RC_MAP_SNAPSTREAM_FIREFLY
+};
static struct usb_device_id ati_remote_table[] = {
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_ati },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_ati },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_ati },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_ati },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_medion },
- { USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
.driver_info = (unsigned long)type_firefly },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_ati
+ },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, LOLA2_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_ati
+ },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, ATI_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_ati
+ },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, NVIDIA_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_ati
+ },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, MEDION_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_medion
+ },
+ {
+ USB_DEVICE(ATI_REMOTE_VENDOR_ID, FIREFLY_REMOTE_PRODUCT_ID),
+ .driver_info = (unsigned long)type_firefly
+ },
{} /* Terminating entry */
};
@@ -215,8 +242,8 @@ MODULE_DEVICE_TABLE(usb, ati_remote_table);
#define SEND_FLAG_COMPLETE 2
/* Device initialization strings */
-static char init1[] = { 0x01, 0x00, 0x20, 0x14 };
-static char init2[] = { 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 };
+static unsigned char init1[] = { 0x01, 0x00, 0x20, 0x14 };
+static unsigned char init2[] = { 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20
};
struct ati_remote {
struct input_dev *idev;
@@ -296,25 +323,8 @@ static const struct {
{KIND_END, 0x00, EV_MAX + 1, 0, 0}
};
-/* Local function prototypes */
-static int ati_remote_sendpacket (struct ati_remote *ati_remote, u16
cmd, unsigned char *data);
-static void ati_remote_irq_out (struct urb *urb);
-static void ati_remote_irq_in (struct urb *urb);
-static void ati_remote_input_report(struct urb *urb);
-static int ati_remote_initialize (struct ati_remote *ati_remote);
-static int ati_remote_probe(struct usb_interface *interface,
Recent update to page_alloc.c causing a crash
Hi, Recently when I updated my driver to 3.5 from 3.3, I am observing that my driver is failing for dma_alloc_coherent, when I traced it, I see lots of changes for MM in 3.5 release any Ideas why this could be happening? Here is the case my driver works fine for 7 runs of the application for 8th time it crashes for MMAP buffers below is the crash log. Thx, --Prabhakar Lad vpif_mmap_loopb: page allocation failure: order:10, mode:0xd0 Backtrace: [c000c608] (dump_backtrace+0x0/0x114) from [c033cfc0] (dump_stack+0x18/0x1c) r6: r5:00d0 r4:0001 r3:c048a060 [c033cfa8] (dump_stack+0x0/0x1c) from [c0061c00] (warn_alloc_failed+0xf4/0x118) [c0061b0c] (warn_alloc_failed+0x0/0x118) from [c00627f4] (__alloc_pages_nodemask+0x544/0x590) r3:c2cfbb64 r2: r7:c04b2f94 r6:c2cfa000 r5:000a r4:00d0 [c00622b0] (__alloc_pages_nodemask+0x0/0x590) from [c000e084] (arm_dma_alloc+0x138/0x358) [c000df4c] (arm_dma_alloc+0x0/0x358) from [c024ca94] (vb2_dma_contig_alloc+0x78/0xfc) [c024ca1c] (vb2_dma_contig_alloc+0x0/0xfc) from [c024a6cc] (__vb2_queue_alloc+0xd4/0x338) r6:c36d5400 r5: r4:c361a190 [c024a5f8] (__vb2_queue_alloc+0x0/0x338) from [c024adfc] (vb2_reqbufs+0x22c/0x308) [c024abd0] (vb2_reqbufs+0x0/0x308) from [c025399c] (vpif_reqbufs+0x114/0x148) r7:0001 r6:c2cfbe20 r5:c361a000 r4:c2d09400 [c0253888] (vpif_reqbufs+0x0/0x148) from [c023a470] (__video_do_ioctl+0x1a14/0x4914) r8:c0145608 r7:c03601e8 r6: r5:c3563000 r4:c2cfbe20 r3: [c0238a5c] (__video_do_ioctl+0x0/0x4914) from [c0238890] (video_usercopy+0x368/0x4b4) [c0238528] (video_usercopy+0x0/0x4b4) from [c02389f0] (video_ioctl2+0x14/0x1c) [c02389dc] (video_ioctl2+0x0/0x1c) from [c02367e8] (v4l2_ioctl+0xac/0x158) [c023673c] (v4l2_ioctl+0x0/0x158) from [c009e67c] (vfs_ioctl+0x28/0x40) r8:c00095a4 r7:0003 r6:c37992b0 r5:c2c77e80 r4:bed27a24 r3:c023673c [c009e654] (vfs_ioctl+0x0/0x40) from [c009edd8] (do_vfs_ioctl+0x52c/0x588) [c009e8ac] (do_vfs_ioctl+0x0/0x588) from [c009ee74] (sys_ioctl+0x40/0x64) r9:c2cfa000 r8:c00095a4 r7:0003 r6:c0145608 r5:bed27a24 r4:c2c77e80 [c009ee34] (sys_ioctl+0x0/0x64) from [c0009420] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:8710 r5: r4:b308 Mem-info: DMA per-cpu: CPU0: hi: 18, btch: 3 usd: 3 active_anon:315 inactive_anon:18 isolated_anon:0 active_file:3 inactive_file:112 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:12196 slab_reclaimable:236 slab_unreclaimable:569 mapped:31 shmem:22 pagetables:34 bounce:0 DMA free:48712kB min:984kB low:1228kB high:1476kB active_anon:1260kB inactive_anon:72kB active_file:12kB inactive_file:560kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:609o lowmem_reserve[]: 0 0 0 DMA: 69*4kB 108*8kB 115*16kB 53*32kB 44*64kB 19*128kB 13*256kB 9*512kB 8*1024kB 11*2048kB 0*4096kB = 48580kB 217 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 15360 pages of RAM 12199 free pages 1335 reserved pages 669 slab pages 155 pages shared 0 pages swap cached vpif_capture vpif_capture: dma_alloc_coherent of size 2622464 failed cannot allocate memory : Cannot allocate memory -- 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: Recent update to page_alloc.c causing a crash
On Mon 2 July 2012 09:25:08 Prabhakar Lad wrote: Hi, Recently when I updated my driver to 3.5 from 3.3, I am observing that my driver is failing for dma_alloc_coherent, when I traced it, I see lots of changes for MM in 3.5 release any Ideas why this could be happening? Here is the case my driver works fine for 7 runs of the application for 8th time it crashes for MMAP buffers below is the crash log. Hi Prabhakar, I've got to ask the obvious question: have you checked that the memory allocated in the first 7 runs is also freed? In other words, aren't you just running out of memory? The other option is memory fragmentation, making it impossible to allocate the contiguous memory that you need. I actually suspect that this is the reason for you running out of memory (it's not a crash, it's just telling you that it can't allocate the memory you need). The only correct way to solve this problem is to use CMA. As far as I can tell you can just configure the amount of CMA memory as a config option or as a kernel parameter (see Documentation/kernel-parameters.txt, search for cma). That should ensure that the amount of memory you need is always available for the buffers. Regards, Hans Thx, --Prabhakar Lad vpif_mmap_loopb: page allocation failure: order:10, mode:0xd0 Backtrace: [c000c608] (dump_backtrace+0x0/0x114) from [c033cfc0] (dump_stack+0x18/0x1c) r6: r5:00d0 r4:0001 r3:c048a060 [c033cfa8] (dump_stack+0x0/0x1c) from [c0061c00] (warn_alloc_failed+0xf4/0x118) [c0061b0c] (warn_alloc_failed+0x0/0x118) from [c00627f4] (__alloc_pages_nodemask+0x544/0x590) r3:c2cfbb64 r2: r7:c04b2f94 r6:c2cfa000 r5:000a r4:00d0 [c00622b0] (__alloc_pages_nodemask+0x0/0x590) from [c000e084] (arm_dma_alloc+0x138/0x358) [c000df4c] (arm_dma_alloc+0x0/0x358) from [c024ca94] (vb2_dma_contig_alloc+0x78/0xfc) [c024ca1c] (vb2_dma_contig_alloc+0x0/0xfc) from [c024a6cc] (__vb2_queue_alloc+0xd4/0x338) r6:c36d5400 r5: r4:c361a190 [c024a5f8] (__vb2_queue_alloc+0x0/0x338) from [c024adfc] (vb2_reqbufs+0x22c/0x308) [c024abd0] (vb2_reqbufs+0x0/0x308) from [c025399c] (vpif_reqbufs+0x114/0x148) r7:0001 r6:c2cfbe20 r5:c361a000 r4:c2d09400 [c0253888] (vpif_reqbufs+0x0/0x148) from [c023a470] (__video_do_ioctl+0x1a14/0x4914) r8:c0145608 r7:c03601e8 r6: r5:c3563000 r4:c2cfbe20 r3: [c0238a5c] (__video_do_ioctl+0x0/0x4914) from [c0238890] (video_usercopy+0x368/0x4b4) [c0238528] (video_usercopy+0x0/0x4b4) from [c02389f0] (video_ioctl2+0x14/0x1c) [c02389dc] (video_ioctl2+0x0/0x1c) from [c02367e8] (v4l2_ioctl+0xac/0x158) [c023673c] (v4l2_ioctl+0x0/0x158) from [c009e67c] (vfs_ioctl+0x28/0x40) r8:c00095a4 r7:0003 r6:c37992b0 r5:c2c77e80 r4:bed27a24 r3:c023673c [c009e654] (vfs_ioctl+0x0/0x40) from [c009edd8] (do_vfs_ioctl+0x52c/0x588) [c009e8ac] (do_vfs_ioctl+0x0/0x588) from [c009ee74] (sys_ioctl+0x40/0x64) r9:c2cfa000 r8:c00095a4 r7:0003 r6:c0145608 r5:bed27a24 r4:c2c77e80 [c009ee34] (sys_ioctl+0x0/0x64) from [c0009420] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:8710 r5: r4:b308 Mem-info: DMA per-cpu: CPU0: hi: 18, btch: 3 usd: 3 active_anon:315 inactive_anon:18 isolated_anon:0 active_file:3 inactive_file:112 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:12196 slab_reclaimable:236 slab_unreclaimable:569 mapped:31 shmem:22 pagetables:34 bounce:0 DMA free:48712kB min:984kB low:1228kB high:1476kB active_anon:1260kB inactive_anon:72kB active_file:12kB inactive_file:560kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:609o lowmem_reserve[]: 0 0 0 DMA: 69*4kB 108*8kB 115*16kB 53*32kB 44*64kB 19*128kB 13*256kB 9*512kB 8*1024kB 11*2048kB 0*4096kB = 48580kB 217 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 15360 pages of RAM 12199 free pages 1335 reserved pages 669 slab pages 155 pages shared 0 pages swap cached vpif_capture vpif_capture: dma_alloc_coherent of size 2622464 failed cannot allocate memory : Cannot allocate memory -- 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: Recent update to page_alloc.c causing a crash
Hi Hans, On Mon, Jul 2, 2012 at 1:19 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Mon 2 July 2012 09:25:08 Prabhakar Lad wrote: Hi, Recently when I updated my driver to 3.5 from 3.3, I am observing that my driver is failing for dma_alloc_coherent, when I traced it, I see lots of changes for MM in 3.5 release any Ideas why this could be happening? Here is the case my driver works fine for 7 runs of the application for 8th time it crashes for MMAP buffers below is the crash log. Hi Prabhakar, I've got to ask the obvious question: have you checked that the memory allocated in the first 7 runs is also freed? In other words, aren't you just running out of memory? Yes Of course, I tested the same application on 3.3 and it works fine. Yes I am running out of memory. The other option is memory fragmentation, making it impossible to allocate the contiguous memory that you need. I actually suspect that this is the reason for you running out of memory (it's not a crash, it's just telling you that it can't allocate the memory you need). Yes its soft crash. The only correct way to solve this problem is to use CMA. As far as I can tell you can just configure the amount of CMA memory as a config option or as a kernel parameter (see Documentation/kernel-parameters.txt, search for cma). That should ensure that the amount of memory you need is always available for the buffers. I tried with cma=60M and its still the same case :( a soft crash. Thx, --Prabhakar Lad Regards, Hans Thx, --Prabhakar Lad vpif_mmap_loopb: page allocation failure: order:10, mode:0xd0 Backtrace: [c000c608] (dump_backtrace+0x0/0x114) from [c033cfc0] (dump_stack+0x18/0x1c) r6: r5:00d0 r4:0001 r3:c048a060 [c033cfa8] (dump_stack+0x0/0x1c) from [c0061c00] (warn_alloc_failed+0xf4/0x118) [c0061b0c] (warn_alloc_failed+0x0/0x118) from [c00627f4] (__alloc_pages_nodemask+0x544/0x590) r3:c2cfbb64 r2: r7:c04b2f94 r6:c2cfa000 r5:000a r4:00d0 [c00622b0] (__alloc_pages_nodemask+0x0/0x590) from [c000e084] (arm_dma_alloc+0x138/0x358) [c000df4c] (arm_dma_alloc+0x0/0x358) from [c024ca94] (vb2_dma_contig_alloc+0x78/0xfc) [c024ca1c] (vb2_dma_contig_alloc+0x0/0xfc) from [c024a6cc] (__vb2_queue_alloc+0xd4/0x338) r6:c36d5400 r5: r4:c361a190 [c024a5f8] (__vb2_queue_alloc+0x0/0x338) from [c024adfc] (vb2_reqbufs+0x22c/0x308) [c024abd0] (vb2_reqbufs+0x0/0x308) from [c025399c] (vpif_reqbufs+0x114/0x148) r7:0001 r6:c2cfbe20 r5:c361a000 r4:c2d09400 [c0253888] (vpif_reqbufs+0x0/0x148) from [c023a470] (__video_do_ioctl+0x1a14/0x4914) r8:c0145608 r7:c03601e8 r6: r5:c3563000 r4:c2cfbe20 r3: [c0238a5c] (__video_do_ioctl+0x0/0x4914) from [c0238890] (video_usercopy+0x368/0x4b4) [c0238528] (video_usercopy+0x0/0x4b4) from [c02389f0] (video_ioctl2+0x14/0x1c) [c02389dc] (video_ioctl2+0x0/0x1c) from [c02367e8] (v4l2_ioctl+0xac/0x158) [c023673c] (v4l2_ioctl+0x0/0x158) from [c009e67c] (vfs_ioctl+0x28/0x40) r8:c00095a4 r7:0003 r6:c37992b0 r5:c2c77e80 r4:bed27a24 r3:c023673c [c009e654] (vfs_ioctl+0x0/0x40) from [c009edd8] (do_vfs_ioctl+0x52c/0x588) [c009e8ac] (do_vfs_ioctl+0x0/0x588) from [c009ee74] (sys_ioctl+0x40/0x64) r9:c2cfa000 r8:c00095a4 r7:0003 r6:c0145608 r5:bed27a24 r4:c2c77e80 [c009ee34] (sys_ioctl+0x0/0x64) from [c0009420] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:8710 r5: r4:b308 Mem-info: DMA per-cpu: CPU0: hi: 18, btch: 3 usd: 3 active_anon:315 inactive_anon:18 isolated_anon:0 active_file:3 inactive_file:112 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:12196 slab_reclaimable:236 slab_unreclaimable:569 mapped:31 shmem:22 pagetables:34 bounce:0 DMA free:48712kB min:984kB low:1228kB high:1476kB active_anon:1260kB inactive_anon:72kB active_file:12kB inactive_file:560kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:609o lowmem_reserve[]: 0 0 0 DMA: 69*4kB 108*8kB 115*16kB 53*32kB 44*64kB 19*128kB 13*256kB 9*512kB 8*1024kB 11*2048kB 0*4096kB = 48580kB 217 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 15360 pages of RAM 12199 free pages 1335 reserved pages 669 slab pages 155 pages shared 0 pages swap cached vpif_capture vpif_capture: dma_alloc_coherent of size 2622464 failed cannot allocate memory : Cannot allocate memory -- 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: Betr: RE: dib0700 can't enable debug messages
Hello, indeed if you are using media build repository, you just need to do make menuconfig, config, gconfig or xconfig in the media build directory and then select Enable extended debug support for all DVB-USB devices. No need to build the full kernel with media build. regards, Olivier From: cedric.dew...@telfort.nl [cedric.dew...@telfort.nl] Sent: Sunday, July 01, 2012 8:52 PM To: Olivier GRENIE; linux-media@vger.kernel.org Subject: Betr: RE: dib0700 can't enable debug messages -- Oorspronkelijk bericht -- Date: Sat, 30 Jun 2012 12:42:29 +0200 From: cedric.dew...@telfort.nl Subject: Betr: RE: dib0700 can't enable debug messages To: Olivier GRENIE olivier.gre...@parrot.com, linux-media@vger.kernel.org linux-media@vger.kernel.org -- Oorspronkelijk bericht -- From: Olivier GRENIE olivier.gre...@parrot.com To: cedric.dew...@telfort.nl cedric.dew...@telfort.nl, linux-media@vger.kernel.org linux-media@vger.kernel.org Date: Fri, 29 Jun 2012 15:25:00 +0100 Subject: RE: dib0700 can't enable debug messages Hello, did you enable the DVB USB debugging (CONFIG_DVB_USB_DEBUG) in your kernel configuration? Hi Olivier, I see in the INSTALL file make xconfig needs the full kernel source. I have fiddled around some with symlinks, but I can't get make xconfig to work: In the media_build directory I have first created a symlink to the freshly downloaded kernel source: $ ls -l scripts - /home/cedric/downloads/linux-3.4.3/scripts/ Then I issued the following command: $ make xconfig make -C /storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l xconfig make[1]: Entering directory `/storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l' make -C /lib/modules/3.3.7-1-ARCH/build -f /storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l/Makefile.kernel config-targets=1 mixed-targets=0 dot-config=0 SRCDIR=/lib/modules/3.3.7-1-ARCH/build v4l-qconf make[2]: Entering directory `/usr/src/linux-3.3.7-1-ARCH' HOSTCC scripts/basic/fixdep scripts/basic/fixdep.c:433:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied compilation terminated. make[3]: *** [scripts/basic/fixdep] Error 1 make[2]: *** [scripts_basic] Error 2 make[2]: Leaving directory `/usr/src/linux-3.3.7-1-ARCH' make[1]: *** [/lib/modules/3.3.7-1-ARCH/build/scripts/kconfig/qconf] Error 2 make[1]: Leaving directory `/storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l' make: *** [xconfig] Error 2 The directory scripts/basic/.fixdep.d is not present: $ ls -lA scripts/basic/ total 20 -rw-r--r-- 1 cedric cedric 10782 Jun 17 20:21 fixdep.c -rw-r--r-- 1 cedric cedric 7 Jun 17 20:21 .gitignore -rw-r--r-- 1 cedric cedric 671 Jun 17 20:21 Makefile Next I goto my kernel directory, and run make xconfig from here: $ cd downloads/linux-3.4.3 [cedric@cedric linux-3.4.3]$ make xconfig HOSTCC scripts/basic/fixdep CHECK qt HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o /usr/bin/moc -i scripts/kconfig/qconf.h -o scripts/kconfig/qconf.moc HOSTCXX scripts/kconfig/qconf.o HOSTLD scripts/kconfig/qconf scripts/kconfig/qconf Kconfig # # using defaults found in arch/x86/configs/x86_64_defconfig # and now back in the media-build directory I run make xconfig again: $ cd tmp/linuxtv-mediabuild/media_build/ [cedric@cedric media_build]$ make xconfig make -C /storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l xconfig make[1]: Entering directory `/storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l' make -C /lib/modules/3.3.7-1-ARCH/build -f /storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l/Makefile.kernel config-targets=1 mixed-targets=0 dot-config=0 SRCDIR=/lib/modules/3.3.7-1-ARCH/build v4l-qconf make[2]: Entering directory `/usr/src/linux-3.3.7-1-ARCH' HOSTCC scripts/basic/fixdep scripts/basic/fixdep.c:433:1: fatal error: opening dependency file scripts/basic/.fixdep.d: Permission denied compilation terminated. make[3]: *** [scripts/basic/fixdep] Error 1 make[2]: *** [scripts_basic] Error 2 make[2]: Leaving directory `/usr/src/linux-3.3.7-1-ARCH' make[1]: *** [/lib/modules/3.3.7-1-ARCH/build/scripts/kconfig/qconf] Error 2 make[1]: Leaving directory `/storage/home/cedric/tmp/linuxtv-mediabuild/media_build/v4l' make: *** [xconfig] Error 2 I don't have the directory .fixdep.d: $ ls -lA scripts/basic/ total 40 -rwxr-xr-x 1 cedric cedric 14561 Jul 1 20:45 fixdep -rw-r--r-- 1 cedric cedric 10782 Jun 17 20:21 fixdep.c -rw-r--r-- 1 cedric cedric 2836 Jul 1 20:45 .fixdep.cmd -rw-r--r-- 1 cedric cedric 7 Jun 17 20:21 .gitignore -rw-r--r-- 1 cedric cedric 671 Jun 17 20:21 Makefile What did I miss? Best regards, Cedric -- 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
[GIT PULL FOR v3.6] Core and vb2 enhancements
Hi all, This is the pull request for the RFC patch series adding core and vb2 enhancements. Changes since the RFCv3 (http://www.spinics.net/lists/linux-media/msg49583.html): - Added vb2_fop_get_unmapped_area (thanks to Scott Jiang for catching that one). - Added vb2_ops_wait_prepare/finish helpers and use them in pwc. - Improved the locking documentation in v4l2-framework.txt. - Rebased to the latest 3.6 code. Regards, Hans The following changes since commit 704a28e88ab6c9cfe393ae626b612cab8b46028e: [media] drxk: prevent doing something wrong when init is not ok (2012-06-29 19:04:32 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git ioctlv6 for you to fetch changes up to 7b030e341a604c56d4ef59062955620ac4c95d05: v4l2-framework.txt: Update the locking documentation. (2012-07-02 10:59:56 +0200) Hans Verkuil (34): v4l2-ioctl.c: move a block of code down, no other changes. v4l2-ioctl.c: introduce INFO_FL_CLEAR to replace switch. v4l2-ioctl.c: v4l2-ioctl: add debug and callback/offset functionality. v4l2-ioctl.c: remove an unnecessary #ifdef. v4l2-ioctl.c: use the new table for querycap and i/o ioctls. v4l2-ioctl.c: use the new table for priority ioctls. v4l2-ioctl.c: use the new table for format/framebuffer ioctls. v4l2-ioctl.c: use the new table for overlay/streamon/off ioctls. v4l2-ioctl.c: use the new table for std/tuner/modulator ioctls. v4l2-ioctl.c: use the new table for queuing/parm ioctls. v4l2-ioctl.c: use the new table for control ioctls. v4l2-ioctl.c: use the new table for selection ioctls. v4l2-ioctl.c: use the new table for compression ioctls. v4l2-ioctl.c: use the new table for debug ioctls. v4l2-ioctl.c: use the new table for preset/timings ioctls. v4l2-ioctl.c: use the new table for the remaining ioctls. v4l2-ioctl.c: finalize table conversion. v4l2-dev.c: add debug sysfs entry. v4l2-ioctl: remove v4l_(i2c_)print_ioctl ivtv: don't mess with vfd-debug. cx18: don't mess with vfd-debug. vb2-core: refactor reqbufs/create_bufs. vb2-core: add support for count == 0 in create_bufs. Spec: document CREATE_BUFS behavior if count == 0. v4l2-dev/ioctl.c: add vb2_queue support to video_device. videobuf2-core: add helper functions. vivi: remove pointless g/s_std support vivi: embed struct video_device instead of allocating it. vivi: use vb2 helper functions. vivi: add create_bufs/preparebuf support. v4l2-dev.c: also add debug support for the fops. pwc: use the new vb2 helpers. pwc: v4l2-compliance fixes. v4l2-framework.txt: Update the locking documentation. Documentation/DocBook/media/v4l/vidioc-create-bufs.xml |8 +- Documentation/video4linux/v4l2-framework.txt | 73 +-- drivers/media/video/cx18/cx18-ioctl.c | 18 - drivers/media/video/cx18/cx18-ioctl.h |2 - drivers/media/video/cx18/cx18-streams.c|4 +- drivers/media/video/ivtv/ivtv-ioctl.c | 12 - drivers/media/video/ivtv/ivtv-ioctl.h |1 - drivers/media/video/ivtv/ivtv-streams.c|4 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c |4 +- drivers/media/video/pwc/pwc-if.c | 171 +- drivers/media/video/pwc/pwc-v4l.c | 165 +- drivers/media/video/pwc/pwc.h |3 - drivers/media/video/sn9c102/sn9c102.h |2 +- drivers/media/video/uvc/uvc_v4l2.c |2 +- drivers/media/video/v4l2-dev.c | 65 +- drivers/media/video/v4l2-ioctl.c | 3285 ++--- drivers/media/video/videobuf2-core.c | 412 ++--- drivers/media/video/vivi.c | 194 +- include/media/v4l2-dev.h |3 + include/media/v4l2-ioctl.h | 25 +- include/media/videobuf2-core.h | 54 ++ 21 files changed, 2196 insertions(+), 2311 deletions(-) -- 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: Question about V4L2_MEMORY_USERPTR
On Sunday 01 July 2012 17:00:58 Sakari Ailus wrote: On Fri, Mar 23, 2012 at 08:19:45AM +0100, Hans Petter Selasky wrote: Hi, I have a question about V4L2_MEMORY_USERPTR: From which context are the kernel's copy_to_user() functions called in relation to V4L2_MEMORY_USERPTR ? Can this be a USB callback function or is it only syscalls, like read/write/ioctl that are allowed to call copy_to_user() ? The reason for asking is that I am maintaining a userland port of the media tree's USB drivers for FreeBSD. At the present moment it is not allowed to call copy_to_user() or copy_from_user() unless the backtrace shows a syscall, so the V4L2_MEMORY_USERPTR feature is simply removed and disabled. I'm currently thinking how I can enable this feature. I hope this is still relevant --- I just read your message the first time. I don't know how V4L2 is being used in FreeBSD userland, but the intent of copy_to_user() function is to copy the contents of kernel memory to somewhere the user space has a mapping to (and the other way around for copy_from_user()). copy_(to|from)_user(), by definition, require a userspace memory context to perform the copy operation. They can't be called from interrupt context, kernel threads, or any other context where no userspace memory context is present. Are your video buffers allocated by the kernel or not? How is USB accessed when you don't have the Linux kernel USB framework around? -- 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
[GIT PULL FOR v3.6] rtl2832 and misc changes
Mauro, That set contains RTL2832 DVB-T demodulator driver by Thomas Mair which was requested earlier too but was not merged. The other part is tda10071 and a8293 changes, two small bug fixes that I *do not want* for 3.5 but 3.6 as those are not critical. regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git misc for you to fetch changes up to 1f2375ea95c221679920f2c88d9defde9ebb4157: a8293: use Kernel dev_* logging (2012-07-02 11:13:58 +0300) Antti Palosaari (5): tda10071: fix DiSEqC message len check tda10071: use decimal numbers for indexes and lengths tda10071: convert Kernel dev_* logging a8293: fix register 00 init value a8293: use Kernel dev_* logging Thomas Mair (5): RTL2832 DVB-T demodulator driver rtl28xxu: support for the rtl2832 demod driver rtl28xxu: renamed rtl2831_rd/rtl2831_wr to rtl28xx_rd/rtl28xx_wr rtl28xxu: support Delock USB 2.0 DVB-T rtl28xxu: support Terratec Noxon DAB/DAB+ stick drivers/media/dvb/dvb-usb/Kconfig |3 + drivers/media/dvb/dvb-usb/dvb-usb-ids.h |3 + drivers/media/dvb/dvb-usb/rtl28xxu.c| 516 +++ drivers/media/dvb/frontends/Kconfig |7 ++ drivers/media/dvb/frontends/Makefile|1 + drivers/media/dvb/frontends/a8293.c | 37 ++ drivers/media/dvb/frontends/rtl2832.c | 823 drivers/media/dvb/frontends/rtl2832.h | 74 drivers/media/dvb/frontends/rtl2832_priv.h | 260 ++ drivers/media/dvb/frontends/tda10071.c | 351 +--- drivers/media/dvb/frontends/tda10071_priv.h | 15 +-- 11 files changed, 1833 insertions(+), 257 deletions(-) create mode 100644 drivers/media/dvb/frontends/rtl2832.c create mode 100644 drivers/media/dvb/frontends/rtl2832.h create mode 100644 drivers/media/dvb/frontends/rtl2832_priv.h -- http://palosaari.fi/ -- 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: Recent update to page_alloc.c causing a crash
Hi Hans, On Mon, Jul 2, 2012 at 1:37 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: Hi Hans, On Mon, Jul 2, 2012 at 1:19 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Mon 2 July 2012 09:25:08 Prabhakar Lad wrote: Hi, Recently when I updated my driver to 3.5 from 3.3, I am observing that my driver is failing for dma_alloc_coherent, when I traced it, I see lots of changes for MM in 3.5 release any Ideas why this could be happening? Here is the case my driver works fine for 7 runs of the application for 8th time it crashes for MMAP buffers below is the crash log. Hi Prabhakar, I've got to ask the obvious question: have you checked that the memory allocated in the first 7 runs is also freed? In other words, aren't you just running out of memory? Yes Of course, I tested the same application on 3.3 and it works fine. Yes I am running out of memory. The other option is memory fragmentation, making it impossible to allocate the contiguous memory that you need. I actually suspect that this is the reason for you running out of memory (it's not a crash, it's just telling you that it can't allocate the memory you need). Yes its soft crash. The only correct way to solve this problem is to use CMA. As far as I can tell you can just configure the amount of CMA memory as a config option or as a kernel parameter (see Documentation/kernel-parameters.txt, search for cma). That should ensure that the amount of memory you need is always available for the buffers. I tried with cma=60M and its still the same case :( a soft crash. Got it fixed problem was with application :) Thx, --Prabhakar Lad Thx, --Prabhakar Lad Regards, Hans Thx, --Prabhakar Lad vpif_mmap_loopb: page allocation failure: order:10, mode:0xd0 Backtrace: [c000c608] (dump_backtrace+0x0/0x114) from [c033cfc0] (dump_stack+0x18/0x1c) r6: r5:00d0 r4:0001 r3:c048a060 [c033cfa8] (dump_stack+0x0/0x1c) from [c0061c00] (warn_alloc_failed+0xf4/0x118) [c0061b0c] (warn_alloc_failed+0x0/0x118) from [c00627f4] (__alloc_pages_nodemask+0x544/0x590) r3:c2cfbb64 r2: r7:c04b2f94 r6:c2cfa000 r5:000a r4:00d0 [c00622b0] (__alloc_pages_nodemask+0x0/0x590) from [c000e084] (arm_dma_alloc+0x138/0x358) [c000df4c] (arm_dma_alloc+0x0/0x358) from [c024ca94] (vb2_dma_contig_alloc+0x78/0xfc) [c024ca1c] (vb2_dma_contig_alloc+0x0/0xfc) from [c024a6cc] (__vb2_queue_alloc+0xd4/0x338) r6:c36d5400 r5: r4:c361a190 [c024a5f8] (__vb2_queue_alloc+0x0/0x338) from [c024adfc] (vb2_reqbufs+0x22c/0x308) [c024abd0] (vb2_reqbufs+0x0/0x308) from [c025399c] (vpif_reqbufs+0x114/0x148) r7:0001 r6:c2cfbe20 r5:c361a000 r4:c2d09400 [c0253888] (vpif_reqbufs+0x0/0x148) from [c023a470] (__video_do_ioctl+0x1a14/0x4914) r8:c0145608 r7:c03601e8 r6: r5:c3563000 r4:c2cfbe20 r3: [c0238a5c] (__video_do_ioctl+0x0/0x4914) from [c0238890] (video_usercopy+0x368/0x4b4) [c0238528] (video_usercopy+0x0/0x4b4) from [c02389f0] (video_ioctl2+0x14/0x1c) [c02389dc] (video_ioctl2+0x0/0x1c) from [c02367e8] (v4l2_ioctl+0xac/0x158) [c023673c] (v4l2_ioctl+0x0/0x158) from [c009e67c] (vfs_ioctl+0x28/0x40) r8:c00095a4 r7:0003 r6:c37992b0 r5:c2c77e80 r4:bed27a24 r3:c023673c [c009e654] (vfs_ioctl+0x0/0x40) from [c009edd8] (do_vfs_ioctl+0x52c/0x588) [c009e8ac] (do_vfs_ioctl+0x0/0x588) from [c009ee74] (sys_ioctl+0x40/0x64) r9:c2cfa000 r8:c00095a4 r7:0003 r6:c0145608 r5:bed27a24 r4:c2c77e80 [c009ee34] (sys_ioctl+0x0/0x64) from [c0009420] (ret_fast_syscall+0x0/0x2c) r7:0036 r6:8710 r5: r4:b308 Mem-info: DMA per-cpu: CPU0: hi: 18, btch: 3 usd: 3 active_anon:315 inactive_anon:18 isolated_anon:0 active_file:3 inactive_file:112 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:12196 slab_reclaimable:236 slab_unreclaimable:569 mapped:31 shmem:22 pagetables:34 bounce:0 DMA free:48712kB min:984kB low:1228kB high:1476kB active_anon:1260kB inactive_anon:72kB active_file:12kB inactive_file:560kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:609o lowmem_reserve[]: 0 0 0 DMA: 69*4kB 108*8kB 115*16kB 53*32kB 44*64kB 19*128kB 13*256kB 9*512kB 8*1024kB 11*2048kB 0*4096kB = 48580kB 217 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 15360 pages of RAM 12199 free pages 1335 reserved pages 669 slab pages 155 pages shared 0 pages swap cached vpif_capture vpif_capture: dma_alloc_coherent of size 2622464 failed cannot allocate memory : Cannot allocate memory -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for 'Coda' video codec IP.
Hi Sascha,
I almost have a final version ready which includes multi-instance
support (not tested though) [1]. As I stated, we assumed the extra
effort of looking at your code in [2] in order to provide a mechanism
that preserves compatibility between VPUs in i.MX21, i.MX51 and
i.MX53. This is the only thing left in order to send the driver for
mainline submission.
While I was reading your code I found out that you keep the following
formats for v1 (codadx6-i.MX27) codec:
static int vpu_v1_codecs[VPU_CODEC_MAX] = {
[VPU_CODEC_AVC_DEC] = 2,
[VPU_CODEC_VC1_DEC] = -1,
[VPU_CODEC_MP2_DEC] = -1,
[VPU_CODEC_DV3_DEC] = -1,
[VPU_CODEC_RV_DEC] = -1,
[VPU_CODEC_MJPG_DEC] = 0x82,
[VPU_CODEC_AVC_ENC] = 3,
[VPU_CODEC_MP4_ENC] = 1,
[VPU_CODEC_MJPG_ENC] = 0x83,
};
As I understand, this means the following operations are supported:
1- H264 decoding.
2- H264 encoding
3- MP4 encoding.
4- MJPG decoding.
5- MJPG encoding.
I totally agree with MP4 and H264 formats but, are you sure about
MJPG? I have a i.MX27 v1 codec (codadx6) but I didn't know that this
codec supported MJPG. Have you tested this code with an i.MX27 and
MJPG? Where did you find out that it supports this format? Are you
using firmware version 2.2.4 for v1 codecs?
Regards.
[1] git://github.com/jmartinc/video_visstrim.git
[2] git://git.pengutronix.de/git/imx/gst-plugins-fsl-vpu.git
[3]
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27nodeId=018rH3ZrDR66AFfpsp=1tab=Design_Tools_Tab
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: [RFC] Support for 'Coda' video codec IP.
On Mon, Jul 02, 2012 at 12:36:46PM +0200, javier Martin wrote:
Hi Sascha,
I almost have a final version ready which includes multi-instance
support (not tested though) [1]. As I stated, we assumed the extra
effort of looking at your code in [2] in order to provide a mechanism
that preserves compatibility between VPUs in i.MX21, i.MX51 and
i.MX53. This is the only thing left in order to send the driver for
mainline submission.
While I was reading your code I found out that you keep the following
formats for v1 (codadx6-i.MX27) codec:
static int vpu_v1_codecs[VPU_CODEC_MAX] = {
[VPU_CODEC_AVC_DEC] = 2,
[VPU_CODEC_VC1_DEC] = -1,
[VPU_CODEC_MP2_DEC] = -1,
[VPU_CODEC_DV3_DEC] = -1,
[VPU_CODEC_RV_DEC] = -1,
[VPU_CODEC_MJPG_DEC] = 0x82,
[VPU_CODEC_AVC_ENC] = 3,
[VPU_CODEC_MP4_ENC] = 1,
[VPU_CODEC_MJPG_ENC] = 0x83,
};
As I understand, this means the following operations are supported:
1- H264 decoding.
2- H264 encoding
3- MP4 encoding.
4- MJPG decoding.
5- MJPG encoding.
I totally agree with MP4 and H264 formats but, are you sure about
MJPG? I have a i.MX27 v1 codec (codadx6) but I didn't know that this
codec supported MJPG. Have you tested this code with an i.MX27 and
MJPG? Where did you find out that it supports this format?
We haven't tested MJPG on the i.MX27. The table above is from the
original Freescale code, so I assume it's correct and I assume that
the coda dx6 can do MJPEG.
Are you
using firmware version 2.2.4 for v1 codecs?
No, 2.2.5
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for 'Coda' video codec IP.
On 2 July 2012 12:54, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 02, 2012 at 12:36:46PM +0200, javier Martin wrote:
Hi Sascha,
I almost have a final version ready which includes multi-instance
support (not tested though) [1]. As I stated, we assumed the extra
effort of looking at your code in [2] in order to provide a mechanism
that preserves compatibility between VPUs in i.MX21, i.MX51 and
i.MX53. This is the only thing left in order to send the driver for
mainline submission.
While I was reading your code I found out that you keep the following
formats for v1 (codadx6-i.MX27) codec:
static int vpu_v1_codecs[VPU_CODEC_MAX] = {
[VPU_CODEC_AVC_DEC] = 2,
[VPU_CODEC_VC1_DEC] = -1,
[VPU_CODEC_MP2_DEC] = -1,
[VPU_CODEC_DV3_DEC] = -1,
[VPU_CODEC_RV_DEC] = -1,
[VPU_CODEC_MJPG_DEC] = 0x82,
[VPU_CODEC_AVC_ENC] = 3,
[VPU_CODEC_MP4_ENC] = 1,
[VPU_CODEC_MJPG_ENC] = 0x83,
};
As I understand, this means the following operations are supported:
1- H264 decoding.
2- H264 encoding
3- MP4 encoding.
4- MJPG decoding.
5- MJPG encoding.
I totally agree with MP4 and H264 formats but, are you sure about
MJPG? I have a i.MX27 v1 codec (codadx6) but I didn't know that this
codec supported MJPG. Have you tested this code with an i.MX27 and
MJPG? Where did you find out that it supports this format?
We haven't tested MJPG on the i.MX27. The table above is from the
original Freescale code, so I assume it's correct and I assume that
the coda dx6 can do MJPEG.
Fabio, could you confirm that the VPU in the i.MX27 supports MJPG too?
Are you
using firmware version 2.2.4 for v1 codecs?
No, 2.2.5
Where did you get that firmware version? The only related download I
can find in [1] is
'MX273DS_FULL_VPU_SW_AND_VPU_FIRMWARE_2.2.4_WINCE_TO2.X_ONLY' which
includes firmware 2.2.4.
[1]
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27nodeId=018rH3ZrDR66AFfpsp=1tab=Design_Tools_Tab
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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 dvb-utils] proper dvb-t scan data for Czech Republic
Pushed, thanks. 2012/6/26 Jiri Slaby jsl...@suse.cz: BTW I would appreciate if you move also dvb-utils to GIT. hg wastes our time. I don't mind, but I won't spend time on that. -- js suse labs Christoph -- 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
[GIT PULL FOR v3.6] cx88: convert to the control framework
Hi all! I didn't get any comments since my RFC post: http://www.spinics.net/lists/linux-media/msg48764.html So it's time to send out the pull request. Regards, Hans The following changes since commit 704a28e88ab6c9cfe393ae626b612cab8b46028e: [media] drxk: prevent doing something wrong when init is not ok (2012-06-29 19:04:32 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cx88 for you to fetch changes up to bc7432646ff6e276bee5490faefb6cd244b95464: cx88-blackbird: replace ioctl by unlocked_ioctl. (2012-07-02 13:47:29 +0200) Hans Verkuil (11): cx88: fix querycap cx88: first phase to convert cx88 to the control framework. cx88: each device node gets the right controls. cx88: convert cx88-blackbird to the control framework. cx88: remove radio and type from cx8800_fh. cx88: move fmt, width and height to cx8800_dev. cx88: add priority support. cx88: support control events. cx88: fix a number of v4l2-compliance violations. cx88: don't use current_norm. cx88-blackbird: replace ioctl by unlocked_ioctl. drivers/media/video/cx88/cx88-alsa.c | 31 +--- drivers/media/video/cx88/cx88-blackbird.c | 234 ++ drivers/media/video/cx88/cx88-cards.c | 20 +++ drivers/media/video/cx88/cx88-core.c |7 +- drivers/media/video/cx88/cx88-video.c | 901 ++ drivers/media/video/cx88/cx88.h | 68 + 6 files changed, 540 insertions(+), 721 deletions(-) -- 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: hacking MT9P031 (LI-5M03) driver in Ubuntu 12.04 on BeagleBoard xM?
Hi Chris, On Thursday 28 June 2012 21:41:16 Chris MacGregor wrote: On 06/27/2012 02:30 AM, Laurent Pinchart wrote: On Thursday 21 June 2012 09:38:11 Chris MacGregor wrote: ... Some of the issues: 1. To get it working, I had to patch in the Aptina driver mods for board- omap3beagle.c etc. I'm not at all sure this is kosher since I'm using the mainline kernel driver, not the Aptina driver (nor the RidgeRun one, in which I had to fix a lot of bugs when we were doing this on a Leopardboard). But without these changes, the camera was not recognized (likely because it wasn't being powered up). I would think that someone out there must be using the driver in the mainline kernel, since it's in there, but how are they getting the camera to be recognized? Unlike on PC hardware, operating systems on embedded hardware usually can't discover devices at runtime. The Linux kernel thus needs a list of the devices present on the system (both inside the SoC and on the board) to handle them properly. That list is usually hardcoded in board code, and the Linux kernel on ARM recently started a migration to the Device Tree that provides such a hardware description from outside the kernel. Devices present inside the SoC or directly on the board are not removable and can be hardcoded in board code or in the device tree. However, devices that come on add-on boards are problematic as they're not always present and can be replaced. Several sensor modules exist for the Beagleboard-xM, we can't hardcode support for one of them in the mainline kernel. There's currently no way to properly support the different sensor modules with a single kernel, mostly because nobody developed a solution so far (although proposals have been posted to mailing lists). For that reason I currently maintain board code with sensor support for several OMAP3 platforms in the omap3isp-sensors-board branch of my git tree at http://git.linuxtv.org/pinchartl/media.git. I'd be happy to push that to mainline if we had a good technical solution. I was expecting that the code would be in there somewhere, but (for the reason you describe) not enabled by default. I was expecting that I might need to tweak the kernel config to enable the sensor support (and indeed I did), but I was very surprised that code necessary to make it actually work was nowhere in sight. I would (naively, perhaps) think that it would be appropriate to have the code present, but enabled only if both MACH_OMAP3_BEAGLE and VIDEO_MT9P031 are enabled. What am I missing? We're trying to move to a single kernel image for all ARMv7 platforms. A compile-time option wouldn't allow that., the option must be runtime- configurable (possibly through a kernel command line argument, or through the device tree). I took a look at your branch (briefly). The Ubuntu 12.04 kernel is currently based on a roughly 3.2.x (maybe 3.2.18?) kernel. Do you happen to have a version of the board files that would be likely to work well on that vintage? No, but it should be very easy to backport the code. Or for that matter, do you have a recommendation as to what (whose) kernel would be my best bet for production use in a BeagleBoard xM (rev C, maybe some B's) using the Leopard Imaging LI-5M03 camera board? I get the sense that the BB xM community is mostly on 3.2.x (or older) at the moment, and I hesitate to assume there isn't a good reason for that. But if some kernel newer than Ubuntu's is reasonably stable and trustworthy on a BB xM, I'd be happy enough to use it. (I do intend to continue with the Ubuntu 12.04 world for everything other than the kernel.) I usually upgrade to the latest stable kernels when they are released, until there's a need to freeze the code base. Depending on your support requirements, picking up a long term stable version can be a good idea. Where did you get the Aptina board code patch from ? From here: https://github.com/Aptina/BeagleBoard-xM That's definitely outdated, the code is based on a very old OMAP3 ISP driver that was more or less broken by design. Nowadays anything other than the mainline version isn't supported by the community. Which is linked to from here: http://blog.galemin.com/2011/04/li-5m03-camera-on-beagleboard-xm/ I started in trying to get the cameras working on our BeagleBoards (as the first step in switching from Leopardboards, with the same cameras), and quickly found that it was not at all obvious how to get the MT9P031 to be recognized in Ubuntu's kernel, nor in Robert C. Nelson's. I googled around and found Max Galemin's stuff, which got me a kernel that recognized the sensor but had some other quirks. Further googling in search of an answer to why it worked in Max's kernel but not the others - despite no visibly relevant difference in the driver sources - led me to the above, or maybe I followed the link from Max's blog - I don't
[GIT PULL FOR v3.6] DVB USB v2
Here it is finally - quite totally rewritten DVB-USB-framework. I haven't got almost any feedback so far... regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git dvb_usb_pull for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898: dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29 +0300) Antti Palosaari (103): dvb_usb_v2: copy current dvb_usb as a starting point dvb_usb_v2: add .init() callback dvb_usb_v2: remove one parameter from dvb_usbv2_device_init() dvb_usb_v2: use .driver_info to pass struct dvb_usb_device_properties dvb_usb_v2: remove owner parameter from dvb_usbv2_device_init() dvb_usb_v2: remove adapter_nums parameter from dvb_usbv2_device_init() dvb_usb_v2: pass (struct dvb_usb_device *) as a parameter for fw download dvb_usb_v2: implement .get_firmware_name() dvb_usb_v2: fix issues raised by checkpatch.pl dvb_usb_v2: pass device name too using (struct usb_device_id) dvb_usb_v2: implement .get_adapter_count() dvb_usb_v2: implement .read_config() dvb_usb_v2: remote controller dvb_usb_v2: restore .firmware - pointer to name dvb_usb_v2: init I2C and USB mutex earlier dvb_usb_v2: remote controller changes dvb_usb_v2: dynamic USB stream URB configuration dvb_usb_v2: usb_urb.c use dynamic debugs dvb_usb_v2: add .get_usb_stream_config() dvb_usb_v2: move (struct usb_data_stream) to one level up dvb_usb_v2: add .get_ts_config() callback dvb_usb_v2: move (struct usb_data_stream_properties) to upper level dvb_usb_v2: move PID filters from frontend to adapter dvb_usb_v2: move 3 callbacks from the frontend to adapter dvb_usb_v2: get rid of (struct dvb_usb_adapter_fe_properties) dvb_usb_v2: remove .num_frontends dvb_usb_v2: delay firmware download as it blocks module init dvb_usb_v2: clean firmware downloading routines dvb_usb_v2: add macro for filling usb_device_id table entry dvb_usb_v2: use dynamic debugs dvb_usb_v2: remove various unneeded variables dvb_usb_v2: frontend switching changes dvb_usb_v2: ensure driver_info is not null dvb_usb_v2: refactor delayed init dvb_usb_v2: remove usb_clear_halt() dvb_usb_v2: unregister all frontends in error case dvb_usb_v2: use Kernel logging (pr_debug/pr_err/pr_info) dvb_usb_v2: move I2C adapter code to different file dvb_usb_v2: rename device_init/device_exit to probe/disconnect dvb_usb_v2: add .bInterfaceNumber match dvb_usb_v2: add missing new line for log writings dvb_usb_v2: fix dvb_usb_generic_rw() debug af9015: switch to new DVB-USB dvb_usb_v2: do not free resources until delayed init is done af9015: use USB core soft_unbind dvb_usb_v2: I2C adapter changes dvb_usb_v2: misc changes dvb_usb_v2: probe/disconnect error handling dvb_usb_v2: add .disconnect() callback dvb_usb_v2: suspend/resume stop/start USB streaming dvb_usb_v2: Cypress firmware download module dvb_usb_v2: move few callbacks one level up dvb_usb_v2: use keyword const for USB ID table af9015: suspend/resume dvb_usb_v2: use pointers to properties ec168: convert to new DVB USB ec168: switch Kernel pr_* logging dvb_usb_v2: do not check active fe when stop streaming ec168: re-implement firmware loading au6610: convert to new DVB USB dvb_usb_v2: move remote controller to the main file ce6230: convert to new DVB USB ce6230: various small changes dvb_usb_v2: attach tuners later anysee: convert to new DVB USB dvb_usb_v2: do not release USB interface when device reconnects dvb_usb_v2: try to remove all adapters on exit dvb_usb_v2: simplify remote init/exit logic dvb_usb_v2: get rid of dvb_usb_device state dvb_usb_v2: move fe_ioctl_override() callback dvb_usb_v2: remove num_frontends_initialized from dvb_usb_adapter dvb_usb_v2: .read_mac_address() callback changes dvb_usb_v2: add macros to fill USB stream properties dvb_usb_v2: change USB stream config logic af9015: update USB streaming configuration logic dvb_usb_v2: helper macros for device/adapter/frontend pointers af9015: use helper macros for some pointers dvb_usb_v2: use lock to sync feed and frontend control af9035: convert to new DVB USB dvb_usb_v2: git rid of dvb_usb_adapter state variable anysee: use DVB USB macros au6610: use DVB USB macros ce6230: use DVB USB macros ec168: use DVB UDB macros dvb_usb_v2: use container_of() for adapter to device dvb_usb_v2: merge
Re: [RFC] Support for 'Coda' video codec IP.
On 2 July 2012 13:13, javier Martin javier.mar...@vista-silicon.com wrote:
On 2 July 2012 12:54, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 02, 2012 at 12:36:46PM +0200, javier Martin wrote:
Hi Sascha,
I almost have a final version ready which includes multi-instance
support (not tested though) [1]. As I stated, we assumed the extra
effort of looking at your code in [2] in order to provide a mechanism
that preserves compatibility between VPUs in i.MX21, i.MX51 and
i.MX53. This is the only thing left in order to send the driver for
mainline submission.
While I was reading your code I found out that you keep the following
formats for v1 (codadx6-i.MX27) codec:
static int vpu_v1_codecs[VPU_CODEC_MAX] = {
[VPU_CODEC_AVC_DEC] = 2,
[VPU_CODEC_VC1_DEC] = -1,
[VPU_CODEC_MP2_DEC] = -1,
[VPU_CODEC_DV3_DEC] = -1,
[VPU_CODEC_RV_DEC] = -1,
[VPU_CODEC_MJPG_DEC] = 0x82,
[VPU_CODEC_AVC_ENC] = 3,
[VPU_CODEC_MP4_ENC] = 1,
[VPU_CODEC_MJPG_ENC] = 0x83,
};
As I understand, this means the following operations are supported:
1- H264 decoding.
2- H264 encoding
3- MP4 encoding.
4- MJPG decoding.
5- MJPG encoding.
I totally agree with MP4 and H264 formats but, are you sure about
MJPG? I have a i.MX27 v1 codec (codadx6) but I didn't know that this
codec supported MJPG. Have you tested this code with an i.MX27 and
MJPG? Where did you find out that it supports this format?
We haven't tested MJPG on the i.MX27. The table above is from the
original Freescale code, so I assume it's correct and I assume that
the coda dx6 can do MJPEG.
Fabio, could you confirm that the VPU in the i.MX27 supports MJPG too?
Are you
using firmware version 2.2.4 for v1 codecs?
No, 2.2.5
Where did you get that firmware version? The only related download I
can find in [1] is
'MX273DS_FULL_VPU_SW_AND_VPU_FIRMWARE_2.2.4_WINCE_TO2.X_ONLY' which
includes firmware 2.2.4.
[1]
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX27nodeId=018rH3ZrDR66AFfpsp=1tab=Design_Tools_Tab
Hi, I was wrong regarding firmware version; we are dealing with 2.2.5
too. Sorry for the noise.
However, it would be great if Fabio could confirm that codadx6 in the
i.MX27 supports MJPG too.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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
[RFC PATCH 0/6] Add frequency band information
Hi all, This patch series adds support for the new VIDIOC_ENUM_FREQ_BANDS ioctl that tells userspace if a tuner supports multiple frequency bands. This API is based on earlier attempts: http://www.spinics.net/lists/linux-media/msg48391.html http://www.spinics.net/lists/linux-media/msg48435.html And an irc discussion: http://linuxtv.org/irc/v4l/index.php?date=2012-06-26 This irc discussion also talked about adding rangelow/high to the v4l2_hw_freq_seek struct, but I decided not to do that. The hwseek additions are independent to this patch series, and I think it is best if Hans de Goede does that part so that that API change can be made together with a driver that actually uses it. In order to show how the new ioctl is used, this patch series adds support for it to the very, very old radio-cadet driver. Comments are welcome! Regards, Hans PS: Mauro, I haven't been able to work on the radio profile yet, so that's not included. -- 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 PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG20x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
+ __u32 reserved[6];
};
struct v4l2_hw_freq_seek {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 seek_upward;
- __u32 wrap_around;
- __u32 spacing;
- __u32 reserved[7];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 seek_upward;
+ __u32 wrap_around;
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
@@ -2646,6 +2658,10 @@ struct v4l2_create_buffers {
#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 99, struct v4l2_dv_timings)
#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 100, struct v4l2_dv_timings_cap)
+/* Experimental, this ioctl may change over the next couple of kernel
+ versions. */
+#define VIDIOC_ENUM_FREQ_BANDS _IOWR('V', 101, struct v4l2_frequency_band)
+
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
1.7.10
--
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 PATCH 5/6] radio-cadet: fix RDS handling.
From: Hans Verkuil hans.verk...@cisco.com
The current RDS code suffered from bit rot. Clean it up and make it work again.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 56 ++---
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 93536b7..d1fb427 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -71,7 +71,7 @@ struct cadet {
int sigstrength;
wait_queue_head_t read_queue;
struct timer_list readtimer;
- __u8 rdsin, rdsout, rdsstat;
+ u8 rdsin, rdsout, rdsstat;
unsigned char rdsbuf[RDS_BUFFER];
struct mutex lock;
int reading;
@@ -85,8 +85,8 @@ static struct cadet cadet_card;
* strength value. These values are in microvolts of RF at the tuner's input.
*/
static __u16 sigtable[2][4] = {
- { 5, 10, 30, 150 },
- { 28, 40, 63, 1000 }
+ { 2185, 4369, 13107, 65535 },
+ { 1835, 2621, 4128, 65535 }
};
@@ -240,10 +240,13 @@ static void cadet_setfreq(struct cadet *dev, unsigned
freq)
cadet_gettune(dev);
if ((dev-tunestat 0x40) == 0) { /* Tuned */
dev-sigstrength = sigtable[dev-curtuner][j];
- return;
+ goto reset_rds;
}
}
dev-sigstrength = 0;
+reset_rds:
+ outb(3, dev-io);
+ outb(inb(dev-io + 1) 0x7f, dev-io + 1);
}
@@ -259,7 +262,7 @@ static void cadet_handler(unsigned long data)
outb(0x80, dev-io); /* Select RDS fifo */
while ((inb(dev-io) 0x80) != 0) {
dev-rdsbuf[dev-rdsin] = inb(dev-io + 1);
- if (dev-rdsin == dev-rdsout)
+ if (dev-rdsin + 1 == dev-rdsout)
printk(KERN_WARNING cadet: RDS buffer
overflow\n);
else
dev-rdsin++;
@@ -278,11 +281,21 @@ static void cadet_handler(unsigned long data)
*/
init_timer(dev-readtimer);
dev-readtimer.function = cadet_handler;
- dev-readtimer.data = (unsigned long)0;
+ dev-readtimer.data = data;
dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(dev-readtimer);
}
+static void cadet_start_rds(struct cadet *dev)
+{
+ dev-rdsstat = 1;
+ outb(0x80, dev-io);/* Select RDS fifo */
+ init_timer(dev-readtimer);
+ dev-readtimer.function = cadet_handler;
+ dev-readtimer.data = (unsigned long)dev;
+ dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
+ add_timer(dev-readtimer);
+}
static ssize_t cadet_read(struct file *file, char __user *data, size_t count,
loff_t *ppos)
{
@@ -291,26 +304,21 @@ static ssize_t cadet_read(struct file *file, char __user
*data, size_t count, lo
int i = 0;
mutex_lock(dev-lock);
- if (dev-rdsstat == 0) {
- dev-rdsstat = 1;
- outb(0x80, dev-io);/* Select RDS fifo */
- init_timer(dev-readtimer);
- dev-readtimer.function = cadet_handler;
- dev-readtimer.data = (unsigned long)dev;
- dev-readtimer.expires = jiffies + msecs_to_jiffies(50);
- add_timer(dev-readtimer);
- }
+ if (dev-rdsstat == 0)
+ cadet_start_rds(dev);
if (dev-rdsin == dev-rdsout) {
if (file-f_flags O_NONBLOCK) {
i = -EWOULDBLOCK;
goto unlock;
}
+ mutex_unlock(dev-lock);
interruptible_sleep_on(dev-read_queue);
+ mutex_lock(dev-lock);
}
while (i count dev-rdsin != dev-rdsout)
readbuf[i++] = dev-rdsbuf[dev-rdsout++];
- if (copy_to_user(data, readbuf, i))
+ if (i copy_to_user(data, readbuf, i))
i = -EFAULT;
unlock:
mutex_unlock(dev-lock);
@@ -345,7 +353,12 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v-rangehigh = 1728000;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
v-audmode = V4L2_TUNER_MODE_STEREO;
- v-rxsubchans |= V4L2_TUNER_SUB_RDS;
+ outb(3, dev-io);
+ outb(inb(dev-io + 1) 0x7f, dev-io + 1);
+ mdelay(100);
+ outb(3, dev-io);
+ if (inb(dev-io + 1) 0x80)
+ v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
@@ -455,9 +468,16 @@ static int cadet_release(struct file *file)
static unsigned int cadet_poll(struct file *file, struct poll_table_struct
*wait)
{
struct cadet *dev = video_drvdata(file);
+ unsigned
[RFC PATCH 2/6] v4l2: add core support for the new VIDIOC_ENUM_FREQ_BANDS ioctl.
From: Hans Verkuil hans.verk...@cisco.com
This adds the usual core support code for this new ioctl.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|1 +
drivers/media/video/v4l2-ioctl.c | 21 +
include/media/v4l2-ioctl.h|2 ++
4 files changed, 25 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 5327ad3..81e5129 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1026,6 +1026,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_ENUM_DV_TIMINGS:
case VIDIOC_QUERY_DV_TIMINGS:
case VIDIOC_DV_TIMINGS_CAP:
+ case VIDIOC_ENUM_FREQ_BANDS:
ret = do_video_ioctl(file, cmd, arg);
break;
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 83dbb2d..4e34808 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -663,6 +663,7 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_S_TUNER, vidioc_s_tuner);
SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
+ SET_VALID_IOCTL(ops, VIDIOC_ENUM_FREQ_BANDS, vidioc_enum_freq_bands);
SET_VALID_IOCTL(ops, VIDIOC_G_SLICED_VBI_CAP, vidioc_g_sliced_vbi_cap);
SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
#ifdef CONFIG_VIDEO_ADV_DEBUG
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index d7fa896..b8e5ef7 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -284,6 +284,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO(VIDIOC_ENUM_DV_TIMINGS, 0),
IOCTL_INFO(VIDIOC_QUERY_DV_TIMINGS, 0),
IOCTL_INFO(VIDIOC_DV_TIMINGS_CAP, 0),
+ IOCTL_INFO(VIDIOC_ENUM_FREQ_BANDS, 0),
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
@@ -1765,6 +1766,26 @@ static long __video_do_ioctl(struct file *file,
ret = ops-vidioc_s_frequency(file, fh, p);
break;
}
+ case VIDIOC_ENUM_FREQ_BANDS:
+ {
+ struct v4l2_frequency_band *p = arg;
+ enum v4l2_tuner_type type;
+
+ type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ if (p-type != type)
+ ret = -EINVAL;
+ else
+ ret = ops-vidioc_enum_freq_bands(file, fh, p);
+ if (!ret)
+ dbgarg(cmd, tuner=%d, index=%d, name=%s,
+ capability=0x%x, rangelow=%d,
+ rangehigh=%d\n,
+ p-tuner, p-index, p-name,
+ p-capability, p-rangelow,
+ p-rangehigh);
+ break;
+ }
case VIDIOC_G_SLICED_VBI_CAP:
{
struct v4l2_sliced_vbi_cap *p = arg;
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index d8b76f7..6d706ab 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -230,6 +230,8 @@ struct v4l2_ioctl_ops {
struct v4l2_frequency *a);
int (*vidioc_s_frequency) (struct file *file, void *fh,
struct v4l2_frequency *a);
+ int (*vidioc_enum_freq_bands) (struct file *file, void *fh,
+ struct v4l2_frequency_band *band);
/* Sliced VBI cap */
int (*vidioc_g_sliced_vbi_cap) (struct file *file, void *fh,
--
1.7.10
--
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 PATCH 4/6] radio-cadet: upgrade to latest frameworks.
From: Hans Verkuil hans.verk...@cisco.com
- add control framework
- use core locking
- use V4L2_TUNER_CAP_LOW
- remove volume support: there is no hardware volume control
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 243 +
1 file changed, 83 insertions(+), 160 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 16a089f..93536b7 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -41,6 +41,9 @@
#include linux/io.h /* outb, outb_p */
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
MODULE_AUTHOR(Fred Gleason, Russell Kroll, Quay Lu, Donald Song, Jason Lewis,
Scott McGrath, William McGrath);
MODULE_DESCRIPTION(A driver for the ADS Cadet AM/FM/RDS radio card.);
@@ -61,8 +64,8 @@ module_param(radio_nr, int, 0);
struct cadet {
struct v4l2_device v4l2_dev;
struct video_device vdev;
+ struct v4l2_ctrl_handler ctrl_handler;
int io;
- int users;
int curtuner;
int tunestat;
int sigstrength;
@@ -94,11 +97,9 @@ static int cadet_getstereo(struct cadet *dev)
if (dev-curtuner != 0) /* Only FM has stereo capability! */
return V4L2_TUNER_SUB_MONO;
- mutex_lock(dev-lock);
outb(7, dev-io); /* Select tuner control */
if ((inb(dev-io + 1) 0x40) == 0)
ret = V4L2_TUNER_SUB_STEREO;
- mutex_unlock(dev-lock);
return ret;
}
@@ -111,8 +112,6 @@ static unsigned cadet_gettune(struct cadet *dev)
* Prepare for read
*/
- mutex_lock(dev-lock);
-
outb(7, dev-io); /* Select tuner control */
curvol = inb(dev-io + 1); /* Save current volume/mute setting */
outb(0x00, dev-io + 1); /* Ensure WRITE-ENABLE is LOW */
@@ -134,8 +133,6 @@ static unsigned cadet_gettune(struct cadet *dev)
* Restore volume/mute setting
*/
outb(curvol, dev-io + 1);
- mutex_unlock(dev-lock);
-
return fifo;
}
@@ -161,7 +158,7 @@ static unsigned cadet_getfreq(struct cadet *dev)
fifo = fifo 1;
}
freq -= 1070; /* IF frequency is 10.7 MHz */
- freq = (freq * 16) / 100; /* Make it 1/16 MHz */
+ freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
}
if (dev-curtuner == 1)/* AM */
freq = ((fifo 0x7fff) - 2010) * 16;
@@ -174,8 +171,6 @@ static void cadet_settune(struct cadet *dev, unsigned fifo)
int i;
unsigned test;
- mutex_lock(dev-lock);
-
outb(7, dev-io);/* Select tuner control */
/*
* Write the shift register
@@ -194,7 +189,6 @@ static void cadet_settune(struct cadet *dev, unsigned fifo)
test = 0x1c | ((fifo 23) 0x02);
outb(test, dev-io + 1);
}
- mutex_unlock(dev-lock);
}
static void cadet_setfreq(struct cadet *dev, unsigned freq)
@@ -209,7 +203,7 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
fifo = 0;
if (dev-curtuner == 0) {/* FM */
test = 102400;
- freq = (freq * 1000) / 16; /* Make it kHz */
+ freq = freq / 16; /* Make it kHz */
freq += 10700; /* IF is 10700 kHz */
for (i = 0; i 14; i++) {
fifo = fifo 1;
@@ -229,10 +223,8 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
* Save current volume/mute setting
*/
- mutex_lock(dev-lock);
outb(7, dev-io);/* Select tuner control */
curvol = inb(dev-io + 1);
- mutex_unlock(dev-lock);
/*
* Tune the card
@@ -240,10 +232,8 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
for (j = 3; j -1; j--) {
cadet_settune(dev, fifo | (j 16));
- mutex_lock(dev-lock);
outb(7, dev-io); /* Select tuner control */
outb(curvol, dev-io + 1);
- mutex_unlock(dev-lock);
msleep(100);
@@ -257,32 +247,6 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
}
-static int cadet_getvol(struct cadet *dev)
-{
- int ret = 0;
-
- mutex_lock(dev-lock);
-
- outb(7, dev-io);/* Select tuner control */
- if ((inb(dev-io + 1) 0x20) != 0)
- ret = 0x;
-
- mutex_unlock(dev-lock);
- return ret;
-}
-
-
-static void cadet_setvol(struct cadet *dev, int vol)
-{
- mutex_lock(dev-lock);
- outb(7, dev-io);/* Select tuner control */
- if (vol 0)
- outb(0x20, dev-io + 1);
-
[RFC PATCH 3/6] v4l2 spec: add VIDIOC_ENUM_FREQ_BANDS documentation.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/compat.xml | 12 ++ Documentation/DocBook/media/v4l/v4l2.xml |6 + .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 152 .../DocBook/media/v4l/vidioc-g-frequency.xml |7 +- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 26 +++- 5 files changed, 194 insertions(+), 9 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index ea42ef8..2ec8000 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2458,6 +2458,15 @@ details./para /orderedlist /section +section + titleV4L2 in Linux 3.6/title + orderedlist +listitem + paraAdded support for frequency band enumerations: VIDIOC-ENUM-FREQ-BANDS;./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title @@ -2587,6 +2596,9 @@ ioctls./para paralink linkend=v4l2-auto-focus-areaconstant V4L2_CID_AUTO_FOCUS_AREA/constant/link control./para /listitem +listitem + paraSupport for frequency band enumeration: VIDIOC-ENUM-FREQ-BANDS; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 008c2d7..c6e307b 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.6/revnumber + date2012-07-02/date + authorinitialshv/authorinitials + revremarkAdded VIDIOC_ENUM_FREQ_BANDS. + /revremark revnumber3.5/revnumber date2012-05-07/date authorinitialssa, sn/authorinitials @@ -534,6 +539,7 @@ and discussions on the V4L mailing list./revremark sub-enum-fmt; sub-enum-framesizes; sub-enum-frameintervals; +sub-enum-freq-bands; sub-enuminput; sub-enumoutput; sub-enumstd; diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml new file mode 100644 index 000..27e264f --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -0,0 +1,152 @@ +refentry id=vidioc-enum-freq-bands + refmeta +refentrytitleioctl VIDIOC_ENUM_FREQ_BANDS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_ENUM_FREQ_BANDS/refname +refpurposeEnumerate supported frequency bands/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_frequency_band +*parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_ENUM_FREQ_BANDS/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraEnumerates the frequency bands that a tuner or modulator supports. +To do this applications initialize the structfieldtuner/structfield, +structfieldtype/structfield and structfieldindex/structfield fields, +and zero out the structfieldreserved/structfield array of a v4l2-frequency-band; and +call the constantVIDIOC_ENUM_FREQ_BANDS/constant ioctl with a pointer +to this structure./para + +paraThis ioctl is supported if the constantV4L2_TUNER_CAP_FREQ_BANDS/constant capability +of the corresponding tuner/modulator is set./para + +table pgwide=1 frame=none id=v4l2-frequency-band + titlestruct structnamev4l2_frequency_band/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldtuner/structfield/entry + entryThe tuner or modulator index number. This is the +same value as in the v4l2-input; structfieldtuner/structfield +field and the
[RFC PATCH 6/6] radio-cadet: implement frequency band enumeration.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-cadet.c | 129 +
1 file changed, 72 insertions(+), 57 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index d1fb427..946a4d7 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -66,7 +66,8 @@ struct cadet {
struct video_device vdev;
struct v4l2_ctrl_handler ctrl_handler;
int io;
- int curtuner;
+ bool is_fm_band;
+ u32 curfreq;
int tunestat;
int sigstrength;
wait_queue_head_t read_queue;
@@ -84,9 +85,9 @@ static struct cadet cadet_card;
* The V4L API spec does not define any particular unit for the signal
* strength value. These values are in microvolts of RF at the tuner's input.
*/
-static __u16 sigtable[2][4] = {
+static u16 sigtable[2][4] = {
+ { 1835, 2621, 4128, 65535 },
{ 2185, 4369, 13107, 65535 },
- { 1835, 2621, 4128, 65535 }
};
@@ -94,7 +95,7 @@ static int cadet_getstereo(struct cadet *dev)
{
int ret = V4L2_TUNER_SUB_MONO;
- if (dev-curtuner != 0) /* Only FM has stereo capability! */
+ if (!dev-is_fm_band) /* Only FM has stereo capability! */
return V4L2_TUNER_SUB_MONO;
outb(7, dev-io); /* Select tuner control */
@@ -149,20 +150,18 @@ static unsigned cadet_getfreq(struct cadet *dev)
/*
* Convert to actual frequency
*/
- if (dev-curtuner == 0) {/* FM */
- test = 12500;
- for (i = 0; i 14; i++) {
- if ((fifo 0x01) != 0)
- freq += test;
- test = test 1;
- fifo = fifo 1;
- }
- freq -= 1070; /* IF frequency is 10.7 MHz */
- freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
+ if (!dev-is_fm_band)/* AM */
+ return ((fifo 0x7fff) - 2010) * 16;
+
+ test = 12500;
+ for (i = 0; i 14; i++) {
+ if ((fifo 0x01) != 0)
+ freq += test;
+ test = test 1;
+ fifo = fifo 1;
}
- if (dev-curtuner == 1)/* AM */
- freq = ((fifo 0x7fff) - 2010) * 16;
-
+ freq -= 1070; /* IF frequency is 10.7 MHz */
+ freq = (freq * 16) / 1000; /* Make it 1/16 kHz */
return freq;
}
@@ -197,11 +196,12 @@ static void cadet_setfreq(struct cadet *dev, unsigned
freq)
int i, j, test;
int curvol;
+ dev-curfreq = freq;
/*
* Formulate a fifo command
*/
fifo = 0;
- if (dev-curtuner == 0) {/* FM */
+ if (dev-is_fm_band) {/* FM */
test = 102400;
freq = freq / 16; /* Make it kHz */
freq += 10700; /* IF is 10700 kHz */
@@ -213,10 +213,9 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
}
test = test 1;
}
- }
- if (dev-curtuner == 1) {/* AM */
- fifo = (freq / 16) + 2010;/* Make it kHz */
- fifo |= 0x10;/* Select AM Band */
+ } else {/* AM */
+ fifo = (freq / 16) + 450; /* Make it kHz */
+ fifo |= 0x10; /* Select AM Band */
}
/*
@@ -239,7 +238,7 @@ static void cadet_setfreq(struct cadet *dev, unsigned freq)
cadet_gettune(dev);
if ((dev-tunestat 0x40) == 0) { /* Tuned */
- dev-sigstrength = sigtable[dev-curtuner][j];
+ dev-sigstrength = sigtable[dev-is_fm_band][j];
goto reset_rds;
}
}
@@ -338,39 +337,50 @@ static int vidioc_querycap(struct file *file, void *priv,
return 0;
}
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .index = 0,
+ .name = AM MW,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 8320, /* 520 kHz */
+ .rangehigh = 26400,/* 1650 kHz */
+ }, {
+ .index = 1,
+ .name = FM,
+ .capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
+ V4L2_TUNER_CAP_RDS_BLOCK_IO | V4L2_TUNER_CAP_LOW |
+ V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 140, /* 87.5 MHz */
+ .rangehigh = 1728000, /* 108.0 MHz */
+ },
+};
+
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
+ if (v-index)
+
Re: [RFC PATCH 0/6] Add frequency band information
Hi, Series looks good to me, ack series: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans On 07/02/2012 04:15 PM, Hans Verkuil wrote: Hi all, This patch series adds support for the new VIDIOC_ENUM_FREQ_BANDS ioctl that tells userspace if a tuner supports multiple frequency bands. This API is based on earlier attempts: http://www.spinics.net/lists/linux-media/msg48391.html http://www.spinics.net/lists/linux-media/msg48435.html And an irc discussion: http://linuxtv.org/irc/v4l/index.php?date=2012-06-26 This irc discussion also talked about adding rangelow/high to the v4l2_hw_freq_seek struct, but I decided not to do that. The hwseek additions are independent to this patch series, and I think it is best if Hans de Goede does that part so that that API change can be made together with a driver that actually uses it. In order to show how the new ioctl is used, this patch series adds support for it to the very, very old radio-cadet driver. Comments are welcome! Regards, Hans PS: Mauro, I haven't been able to work on the radio profile yet, so that's not included. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] Add frequency band information
Hi, This looks good to me Acked-by: Manjunatha Halli manjunatha_ha...@ti.com Regards Manju On Mon, Jul 2, 2012 at 9:42 AM, Hans de Goede hdego...@redhat.com wrote: Hi, Series looks good to me, ack series: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans On 07/02/2012 04:15 PM, Hans Verkuil wrote: Hi all, This patch series adds support for the new VIDIOC_ENUM_FREQ_BANDS ioctl that tells userspace if a tuner supports multiple frequency bands. This API is based on earlier attempts: http://www.spinics.net/lists/linux-media/msg48391.html http://www.spinics.net/lists/linux-media/msg48435.html And an irc discussion: http://linuxtv.org/irc/v4l/index.php?date=2012-06-26 This irc discussion also talked about adding rangelow/high to the v4l2_hw_freq_seek struct, but I decided not to do that. The hwseek additions are independent to this patch series, and I think it is best if Hans de Goede does that part so that that API change can be made together with a driver that actually uses it. In order to show how the new ioctl is used, this patch series adds support for it to the very, very old radio-cadet driver. Comments are welcome! Regards, Hans PS: Mauro, I haven't been able to work on the radio profile yet, so that's not included. -- Regards Halli -- 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 v2] implicit drm synchronization wip with dma-buf
Well,
V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain
some nice code.
My goal was to extend dma-buf in a generic way now, some elements from v1 are
remaining,
most notably a dma-buf used for syncing. However it is expected now that
dma-buf syncing will
work in a very specific way now, slightly more strict than in v1.
Instead of each buffer having their own dma-buf I put in 1 per command
submission.
This submission hasn't been run-time tested yet, but I expect the api to go
something like this.
Intended to be used like this:
list_init(head);
add_list_tail(validate1-entry, head);
add_list_tail(validate2-entry, head);
add_list_tail(validate3-entry, head);
r = dmabufmgr_eu_reserve_buffers(head);
if (r) return r;
// add waits on cpu or gpu
list_for_each_entry(validate, ...) {
if (!validate-sync_buf)
continue;
// Check attachments to see if we already imported sync_buf
// somewhere, if not attach to it.
// waiting until cur_seq - dmabuf-sync_val = 0 on either cpu
// or as command submitted to gpu
// sync_buf itself is a dma-buf, so it should be trivial
// TODO: sync_buf should NEVER be validated, add is_sync_buf to dma_buf?
// If this step fails: dmabufmgr_eu_backoff_reservation
// else:
// dmabufmgr_eu_fence_buffer_objects(our_own_sync_buf,
// hwchannel * max(minhwalign, 4), ++counter[hwchannel]);
// XXX: Do we still require a minimum alignment? I set up 16 for
nouveau,
// but this is no longer needed in this design since it only matters
// for writes for which nouveau would already control the offset.
}
// Some time after execbuffer was executed, doesn't have to be right away but
before
// getting in the danger of our own counter wrapping around:
// grab dmabufmgr.lru_lock, and cleanup by unreffing sync_buf when
// sync_buf == ownbuf, sync_ofs == ownofs, and sync_val == saved_counter
// In the meantime someone else or even us might have reserved this
dma_buf
// again, which is why all those checks are needed before unreffing.
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..86e7598 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-buf-mgr.o dma-buf-mgr-eu.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf-mgr-eu.c b/drivers/base/dma-buf-mgr-eu.c
new file mode 100644
index 000..27ebc68
--- /dev/null
+++ b/drivers/base/dma-buf-mgr-eu.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on ttm_bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include linux/dma-buf-mgr.h
+#include linux/sched.h
+#include linux/export.h
+
+static void dmabufmgr_eu_backoff_reservation_locked(struct list_head *list)
+{
+ struct dmabufmgr_validate *entry;
+
+ list_for_each_entry(entry, list, head) {
+ struct dma_buf *bo = entry-bo;
+ if (!entry-reserved)
+ continue;
+
+ entry-reserved = false;
+ atomic_set(bo-reserved, 0);
+ wake_up_all(bo-event_queue);
+ if (entry-sync_buf)
+ dma_buf_put(entry-sync_buf);
+
pctv452e
I've been using a Technotrend TT 3600 USB DVB-S2 receiver for a couple of years, which has (largely) been working fine under the S2-liplianin pctv452e driver. I've been aware of a lot of documented problems with running this receiver under the 3.x kernel, so I've stuck with the 2.6 series kernels. Unfortunately I've now had to upgrade to the 3.2.0 kernel for other unrelated reasons, and it seems that the device is more or less unusable under this kernel. With the stock 3.2.0 kernel, the driver produces numerous I2C errors and is quite unreliable. The I2C errors seem to be produced exclusively as a result of stb_6100_read_reg() reading register F, and notably all calls to stb6100_read_regs() seem to succeed, so I've replaced the stb_6100_read_reg() function with a call to stb6100_read_regs(), so it reads all the registers and then returns the requested one, rather than reading just the requested register. This seems to make the I2C errors disappear. However, the card is still very unreliable - after about 5 minutes of receiving a channel (using MythTV), it breaks. No errors logged in dmesg, but MythTV logs: DevRdB(/dev/dvb/adapter0/frontend0) Error: Poll giving up DVBSH(/dev/dvb/adapter0/frontend0) Error: Device error detected DVBRec(7:/dev/dvb/adapter0/frontend0) Error: Stream handler died unexpectedly. Can anyone give me any pointers that might help? I've searched and searched and all I can see if people saying that it won't work since the DVB-S2 code was integrated into the kernel tree, but I've not seen anyone try to figure out _why_ it won't work. Thanks. -- - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] videodev2.h: add VIDIOC_ENUM_FREQ_BANDS.
Em 02-07-2012 11:15, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..d54ec6e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2048,6 +2048,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_FREQ_BANDS0x0400
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2066,19 +2067,30 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
struct v4l2_frequency {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 frequency;
- __u32 reserved[8];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 frequency;
+ __u32 reserved[8];
+};
+
+struct v4l2_frequency_band {
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 index;
+ __u32 capability;
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u8name[32];
As we've discussed, band name can be inferred from the frequency.
Also, there are more than one name for the same band (it could be
named based on the wavelength or frequency - also, some bands or
band segments may have special names, like Tropical Wave).
Let's userspace just call it whatever it wants. So, I'll just
drop it.
On the other hand, the modulation is independent on the band, and
ITU-R and regulator agencies may allow more than one modulation type
and usage for the same frequency (like primary and secondary usage).
So, it makes sense to have an enum here to describe the modulation type
(currenly, AM, FM and VSB).
+ __u32 reserved[6];
};
struct v4l2_hw_freq_seek {
- __u32 tuner;
- __u32 type; /* enum v4l2_tuner_type */
- __u32 seek_upward;
- __u32 wrap_around;
- __u32 spacing;
- __u32 reserved[7];
+ __u32 tuner;
+ __u32 type; /* enum v4l2_tuner_type */
+ __u32 seek_upward;
+ __u32 wrap_around;
+ __u32 spacing;
+ __u32 reserved[7];
};
/*
@@ -2646,6 +2658,10 @@ struct v4l2_create_buffers {
#define VIDIOC_QUERY_DV_TIMINGS _IOR('V', 99, struct v4l2_dv_timings)
#define VIDIOC_DV_TIMINGS_CAP _IOWR('V', 100, struct v4l2_dv_timings_cap)
+/* Experimental, this ioctl may change over the next couple of kernel
+ versions. */
+#define VIDIOC_ENUM_FREQ_BANDS _IOWR('V', 101, struct
v4l2_frequency_band)
+
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
--
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: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jul 2 19:00:19 CEST 2012 git hash:704a28e88ab6c9cfe393ae626b612cab8b46028e gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about V4L2_MEMORY_USERPTR
Hi Laurent and Sakari, For the sake of the matter, here is the driver in question: http://www.freshports.org/multimedia/webcamd/ Under native-Linux (kernel mode): I've looked at the linux-media code a bit and it appears that video data is copied directly from the USB callback functions to the destination process in userspace. This works because the userspace buffer is mapped into kernel memory it appears. Correct me if I'm wrong: video/videobuf-core.c: err = __videobuf_mmap_setup(q, count, size, V4L2_MEMORY_USERPTR); Under FreeBSD where the Linux kernel code is running in user-space as a driver daemon, this part cannot be done exactly like this, so I've just patched out the V4L2_MEMORY_USERPTR feature until further. Am I clear? --HPS On Monday 02 July 2012 11:24:15 Laurent Pinchart wrote: On Sunday 01 July 2012 17:00:58 Sakari Ailus wrote: On Fri, Mar 23, 2012 at 08:19:45AM +0100, Hans Petter Selasky wrote: Hi, I have a question about V4L2_MEMORY_USERPTR: From which context are the kernel's copy_to_user() functions called in relation to V4L2_MEMORY_USERPTR ? Can this be a USB callback function or is it only syscalls, like read/write/ioctl that are allowed to call copy_to_user() ? The reason for asking is that I am maintaining a userland port of the media tree's USB drivers for FreeBSD. At the present moment it is not allowed to call copy_to_user() or copy_from_user() unless the backtrace shows a syscall, so the V4L2_MEMORY_USERPTR feature is simply removed and disabled. I'm currently thinking how I can enable this feature. I hope this is still relevant --- I just read your message the first time. I don't know how V4L2 is being used in FreeBSD userland, but the intent of copy_to_user() function is to copy the contents of kernel memory to somewhere the user space has a mapping to (and the other way around for copy_from_user()). copy_(to|from)_user(), by definition, require a userspace memory context to perform the copy operation. They can't be called from interrupt context, kernel threads, or any other context where no userspace memory context is present. Are your video buffers allocated by the kernel or not? How is USB accessed when you don't have the Linux kernel USB framework around? -- 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
