Re: Comparisons of images between Dazzle DVC100, EasyCap stk1160 and Hauppauge ImapctVCB-e in Linux.
Hi Guys, (I'm copying Ezequial on this because of the work he has done on the stk1160). My colleague (a Doctor) had this to say on the medical images I posted earlier (see below): The impactVCB-e image is redder and less clear. The dvc100 and easycap seem similar to me and both of them are not as good as the original one. So I have to ask how is it that the cheap little EasyCap is performing at the same level as the Dazzle DVC100 and better than the ImpactVCB-e? It seems to me that the more complex and expensive DVC100 and ImpactVCB-e should perform well and that the EasyCap should be the runner up. If the DVC100 and ImpactVCB-e had had the same love and attention that Ezequial has shown the EasyCap would they outperform it? The ImpactVCB-e is easier to use internally and the Dazzle is external. Does the fact that the ImpactVCB-e has a PCI-e connector help it at all? Otherwise I should just focus on EasyCap for my raw SD capture and move on. Thanks, Steve On 23/04/14 16:22, Steve Cookson wrote: Hi Guys, I would be interested in your views of the comparisons of these images. The still is the image of a duodenum taken during an endoscopy and recorded to a DVD player (via an s-video or composite cable). Although the endoscope is an HD endoscope, the DVD recorder isn't and the resulting video is 720x480i59.94. Here are further details of the video:- Format : MPEG Video v2 Format profile : Main@Main Format settings, BVOP : Yes, Matrix : Custom, GOP : M=3, N=15 Bit rate mode : Variable Bit rate : 4 566 Kbps Maximum bit rate : 10 000 Kbps Width : 720 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate : 29.970 fps Standard : NTSC Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 0.441 The video was played through Dragon Player and the video signal has exited through a mini-VGA port defined as 640x480 and passed through a VGA-S-Video converter to an s-video cable. The cable has in turn been connected in turn to a Dazzle DVC100, an EasyCap stk1160 and a Hauppauge ImapctVCB-e. Each setting (eg brightness and contrast etc) has as near as possible to mid-range and a screengrab taken. The results are shown here: Original: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMrgmD6gSf74Ih4l5k2TGxc Dazzle DVC100: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMaOf4QTsIefYh4l5k2TGxc ImpactVCB-e: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcM7i72IqGujuIh4l5k2TGxc STK1160: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcPO7kmQk/IS94h4l5k2TGxc I would be grateful for your views on the quality of the images. Is one of materially higher quality than the others, or can I adjust the settings to improve the quality of one of them more. It seems to me that the Hauppauge is marginally better than the others. What do you think? Can I improve the test? Regards 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 -- 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: Comparisons of images between Dazzle DVC100, EasyCap stk1160 and Hauppauge ImapctVCB-e in Linux.
Doh, HTML cause vger to drop it. Resending. On Fri, Apr 25, 2014 at 8:47 AM, Steven Toth st...@kernellabs.com wrote: On Fri, Apr 25, 2014 at 8:19 AM, Steve Cookson i...@sca-uk.com wrote: Hi Guys, Hello again. (I'm copying Ezequial on this because of the work he has done on the stk1160). My colleague (a Doctor) had this to say on the medical images I posted earlier (see below): The impactVCB-e image is redder and less clear. The dvc100 and easycap seem similar to me and both of them are not as good as the original one. So I have to ask how is it that the cheap little EasyCap is performing at the same level as the Dazzle DVC100 and better than the ImpactVCB-e? Its usually either because the Linux engineers simply aren't focused on improving quality for the last 'mile', or that the ADC/Video digitizer differers between products. 'Redder' isn't usually a differentiation between video digitizer silicon, its miss-configuration - for example. It seems to me that the more complex and expensive DVC100 and ImpactVCB-e should perform well and that the EasyCap should be the runner up. Not necessarily, but I can understand why you may think that. The reality is - you are measuring the work of individuals who we're not paid to create these Linux drivers. They work well enough for their needs, they scratched their own itch, then they moved on, more than likely this is the case. So, you are seeing a mixture of different silicon, different attention to detail, different default values and different levels of commitment in the driver developers. If the DVC100 and ImpactVCB-e had had the same love and attention that Ezequial has shown the EasyCap would they outperform it? Hard to say. With my experience working for Hauppauge, directly in their engineering team, having worked on literally hundreds of products, lots of different video digitizer, they're all fairly close quality wise in general, with good signals, with the right drivers. What makes a good video digitizer stand out from a poor one, it how it performs in very poor signal conditions. The ImpactVCB-e is easier to use internally and the Dazzle is external. Does the fact that the ImpactVCB-e has a PCI-e connector help it at all? Invariably not. Otherwise I should just focus on EasyCap for my raw SD capture and move on. You need to make that judgement call. If you are building a business around medical imaging and have no engineering capability to improve drivers, go with what your gut says and what's available to you today. You shouldn't rely on the good will of Linux engineers to fix your business requirements in their spare time, in the coming weeks or months. Or, hire a consultant to improve the drivers for you and the rest of the Linux community. This what everyone else does. - Steve Thanks, Steve On 23/04/14 16:22, Steve Cookson wrote: Hi Guys, I would be interested in your views of the comparisons of these images. The still is the image of a duodenum taken during an endoscopy and recorded to a DVD player (via an s-video or composite cable). Although the endoscope is an HD endoscope, the DVD recorder isn't and the resulting video is 720x480i59.94. Here are further details of the video:- Format : MPEG Video v2 Format profile : Main@Main Format settings, BVOP : Yes, Matrix : Custom, GOP : M=3, N=15 Bit rate mode : Variable Bit rate : 4 566 Kbps Maximum bit rate : 10 000 Kbps Width : 720 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate : 29.970 fps Standard : NTSC Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 0.441 The video was played through Dragon Player and the video signal has exited through a mini-VGA port defined as 640x480 and passed through a VGA-S-Video converter to an s-video cable. The cable has in turn been connected in turn to a Dazzle DVC100, an EasyCap stk1160 and a Hauppauge ImapctVCB-e. Each setting (eg brightness and contrast etc) has as near as possible to mid-range and a screengrab taken. The results are shown here: Original: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMrgmD6gSf74Ih4l5k2TGxc Dazzle DVC100: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcMaOf4QTsIefYh4l5k2TGxc ImpactVCB-e: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcM7i72IqGujuIh4l5k2TGxc STK1160: http://tinypic.com/usermedia.php?uo=fNkd6hpTbcPO7kmQk/IS94h4l5k2TGxc I would be grateful for your views on the quality of the images. Is one of materially higher quality than the others, or can I adjust the settings to improve the quality of one of them more. It seems to me that the Hauppauge is marginally better than the others. What do you think? Can I improve the test? Regards Steve. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: Comparisons of images between Dazzle DVC100, EasyCap stk1160 and Hauppauge ImapctVCB-e in Linux.
I looked at the pictures as well and I noticed a few things: The aspect ratio of the impactvcb-e isn't right, it's too narrow. What width and height did you specify when capturing? I can't test this myself as I'm abroad, but try 720x480 or 768x480. I also noticed that the cx23885 driver selects slightly incorrect default brightness, contrast and saturation values. Whether that is the cause of the color differences is debatable, but you can try using my repo: git://linuxtv.org/hverkuil/media_tree.git Checkout the cx23 branch. This branch contains a pile of cleanup patches including a conversion to the control framework, which should ensure correct (to my knowledge) defaults for the color controls. Regards, Hans On 04/25/2014 02:48 PM, Steven Toth wrote: Doh, HTML cause vger to drop it. Resending. On Fri, Apr 25, 2014 at 8:47 AM, Steven Toth st...@kernellabs.com wrote: On Fri, Apr 25, 2014 at 8:19 AM, Steve Cookson i...@sca-uk.com wrote: Hi Guys, Hello again. (I'm copying Ezequial on this because of the work he has done on the stk1160). My colleague (a Doctor) had this to say on the medical images I posted earlier (see below): The impactVCB-e image is redder and less clear. The dvc100 and easycap seem similar to me and both of them are not as good as the original one. So I have to ask how is it that the cheap little EasyCap is performing at the same level as the Dazzle DVC100 and better than the ImpactVCB-e? Its usually either because the Linux engineers simply aren't focused on improving quality for the last 'mile', or that the ADC/Video digitizer differers between products. 'Redder' isn't usually a differentiation between video digitizer silicon, its miss-configuration - for example. It seems to me that the more complex and expensive DVC100 and ImpactVCB-e should perform well and that the EasyCap should be the runner up. Not necessarily, but I can understand why you may think that. The reality is - you are measuring the work of individuals who we're not paid to create these Linux drivers. They work well enough for their needs, they scratched their own itch, then they moved on, more than likely this is the case. So, you are seeing a mixture of different silicon, different attention to detail, different default values and different levels of commitment in the driver developers. If the DVC100 and ImpactVCB-e had had the same love and attention that Ezequial has shown the EasyCap would they outperform it? Hard to say. With my experience working for Hauppauge, directly in their engineering team, having worked on literally hundreds of products, lots of different video digitizer, they're all fairly close quality wise in general, with good signals, with the right drivers. What makes a good video digitizer stand out from a poor one, it how it performs in very poor signal conditions. The ImpactVCB-e is easier to use internally and the Dazzle is external. Does the fact that the ImpactVCB-e has a PCI-e connector help it at all? Invariably not. Otherwise I should just focus on EasyCap for my raw SD capture and move on. You need to make that judgement call. If you are building a business around medical imaging and have no engineering capability to improve drivers, go with what your gut says and what's available to you today. You shouldn't rely on the good will of Linux engineers to fix your business requirements in their spare time, in the coming weeks or months. Or, hire a consultant to improve the drivers for you and the rest of the Linux community. This what everyone else does. - Steve Thanks, Steve On 23/04/14 16:22, Steve Cookson wrote: Hi Guys, I would be interested in your views of the comparisons of these images. The still is the image of a duodenum taken during an endoscopy and recorded to a DVD player (via an s-video or composite cable). Although the endoscope is an HD endoscope, the DVD recorder isn't and the resulting video is 720x480i59.94. Here are further details of the video:- Format : MPEG Video v2 Format profile : Main@Main Format settings, BVOP : Yes, Matrix : Custom, GOP : M=3, N=15 Bit rate mode : Variable Bit rate : 4 566 Kbps Maximum bit rate : 10 000 Kbps Width : 720 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate : 29.970 fps Standard : NTSC Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Compression mode : Lossy Bits/(Pixel*Frame) : 0.441 The video was played through Dragon Player and the video signal has exited through a mini-VGA port defined as 640x480 and passed through a VGA-S-Video converter to an s-video cable. The cable has in turn been connected in turn to a Dazzle DVC100, an EasyCap stk1160 and a Hauppauge ImapctVCB-e. Each setting (eg brightness and contrast etc) has as near as possible to mid-range and a screengrab taken. The results are shown here:
Re: Comparisons of images between Dazzle DVC100, EasyCap stk1160 and Hauppauge ImapctVCB-e in Linux.
On Apr 25, Steve Cookson wrote: [..] If the DVC100 and ImpactVCB-e had had the same love and attention that Ezequial has shown the EasyCap would they outperform it? I really appreciate the kind words and I'm happy to see the driver is being used and works well. However, to be fair, the stk1160 is just a little link in a larger chain. The video decoder is controlled through another driver (saa7115) and so I've little merit in the image quality. [..] Otherwise I should just focus on EasyCap for my raw SD capture and move on. Hm.. hard to say. Easycap stk1160 devices are hard to get, it seems they are manufactured in a few different hardware flavors (but with the same case) and it's hard to tell what flavor you buy. Right now, I think we've supported the two stk1160 cases, but there's a third Easycap variant currently unsupported (which doesn't use stk1160 but a Somagic chipset). In addition, given the stk1160 was partly reverse-engineered, partly based on a non-public and very laconic datasheet, it's not easy to fix given the lack of details about the chip. In conclusion, if you pick stk1160, make sure you buy enough Easycap devices (from the same provider) and do some extra effort to test *each* of them to ensure they work as you expect. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] videobuf2-dma-sg: Fix NULL pointer dereference BUG
vb2_get_vma() copy the content of the vma to a new structure but set some of its pointers to NULL. One of this pointer is used by follow_pte() called by follow_pfn() on io memory. This can lead to a NULL pointer derreference. The version of vma that has not been cleared must be used. [ 406.143320] BUG: unable to handle kernel NULL pointer dereference at 0040 [ 406.143427] IP: [8115204c] follow_pfn+0x2c/0x70 [ 406.143491] PGD 6c3f0067 PUD 6c3ef067 PMD 0 [ 406.143546] Oops: [#1] SMP [ 406.143587] Modules linked in: qtec_mem qt5023_video qtec_testgen qtec_xform videobuf2_core gpio_xilinx videobuf2_vmalloc videobuf2_dma_sg qtec_cmosis videobuf2_memops qtec_pcie qtec_white fglrx(PO) qt5023 spi_xilinx spi_bitbang [ 406.143852] CPU: 0 PID: 299 Comm: tracker Tainted: P O 3.13.0-qtec-standard #10 [ 406.143927] Hardware name: QTechnology QT5022/QT5022, BIOS PM_2.1.0.309 X64 04/04/2013 [ 406.144000] task: 880085c82d60 ti: 880085abe000 task.ti: 880085abe000 [ 406.144067] RIP: 0010:[8115204c] [8115204c] follow_pfn+0x2c/0x70 [ 406.144145] RSP: 0018:880085abf888 EFLAGS: 00010296 [ 406.144195] RAX: RBX: 880085abf8e0 RCX: 880085abf888 [ 406.144260] RDX: 880085abf890 RSI: 7fc52e173000 RDI: 8800863cbe40 [ 406.144325] RBP: 880085abf8a8 R08: 0018 R09: 8800863cbf00 [ 406.144388] R10: 880086703b80 R11: 01e0 R12: 00018000 [ 406.144452] R13: R14: ea00 R15: 88015922fea0 [ 406.144517] FS: 7fc536e7c740() GS:88015ec0() knlGS: [ 406.144591] CS: 0010 DS: ES: CR0: 80050033 [ 406.144644] CR2: 0040 CR3: 66c9d000 CR4: 07f0 [ 406.144708] Stack: [ 406.144731] 00018000 7fc52e18b000 7fc52e173000 [ 406.144813] 880085abf918 a083b2fd 880085ab1ba8 [ 406.144894] 0001 880085abf928 880159a20800 [ 406.144976] Call Trace: [ 406.145011] [a083b2fd] vb2_dma_sg_get_userptr+0x14d/0x310 [videobuf2_dma_sg] [ 406.145089] [a08507df] __qbuf_userptr+0xbf/0x3e0 [videobuf2_core] [ 406.147229] [a0041454] ? mc_heap_lock_memory+0x1f4/0x490 [fglrx] [ 406.149234] [813428f3] ? cpumask_next_and+0x23/0x50 [ 406.151223] [810b2e38] ? enqueue_task_fair+0x658/0xde0 [ 406.153199] [81061888] ? native_smp_send_reschedule+0x48/0x60 [ 406.155184] [815836b9] ? get_ctrl+0xa9/0xd0 [ 406.157161] [8116f4e4] ? __kmalloc+0x1a4/0x1b0 [ 406.159135] [a0850b9c] ? __vb2_queue_alloc+0x9c/0x4a0 [videobuf2_core] [ 406.161130] [a0852d08] __buf_prepare+0x1a8/0x210 [videobuf2_core] [ 406.163171] [a0854c57] __vb2_qbuf+0x27/0xcc [videobuf2_core] [ 406.165229] [a0851dfd] vb2_queue_or_prepare_buf+0x1ed/0x270 [videobuf2_core] [ 406.167325] [a0854c30] ? vb2_ioctl_querybuf+0x30/0x30 [videobuf2_core] [ 406.169419] [a0851e9c] vb2_qbuf+0x1c/0x20 [videobuf2_core] [ 406.171508] [a0851ef8] vb2_ioctl_qbuf+0x58/0x70 [videobuf2_core] [ 406.173604] [8157d3a8] v4l_qbuf+0x48/0x60 [ 406.175681] [8157b29c] __video_do_ioctl+0x2bc/0x340 [ 406.19] [8116f43c] ? __kmalloc+0xfc/0x1b0 [ 406.179883] [8157cd0e] ? video_usercopy+0x7e/0x470 [ 406.181961] [8157ce81] video_usercopy+0x1f1/0x470 [ 406.184021] [8157afe0] ? v4l_printk_ioctl+0xb0/0xb0 [ 406.186085] [810ae1ed] ? account_system_time+0x8d/0x190 [ 406.188149] [8157d115] video_ioctl2+0x15/0x20 [ 406.190216] [815781b3] v4l2_ioctl+0x123/0x160 [ 406.192251] [810ce415] ? rcu_eqs_enter+0x65/0xa0 [ 406.194256] [81186b28] do_vfs_ioctl+0x88/0x560 [ 406.196258] [810ae145] ? account_user_time+0x95/0xb0 [ 406.198262] [810ae6a4] ? vtime_account_user+0x44/0x70 [ 406.200215] [81187091] SyS_ioctl+0x91/0xb0 [ 406.202107] [817be109] tracesys+0xd0/0xd5 [ 406.203946] Code: 66 66 66 90 48 f7 47 50 00 44 00 00 b8 ea ff ff ff 74 52 55 48 89 e5 53 48 89 d3 48 8d 4d e0 48 8d 55 e8 48 83 ec 18 48 8b 47 40 48 8b 78 40 e8 8b fe ff ff 85 c0 75 27 48 8b 55 e8 48 b9 00 f0 [ 406.208011] RIP [8115204c] follow_pfn+0x2c/0x70 [ 406.209908] RSP 880085abf888 [ 406.211760] CR2: 0040 [ 406.213676] ---[ end trace 996d9f64e6739a04 ]--- Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com --- drivers/media/v4l2-core/videobuf2-dma-sg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c index c779f21..adefc31 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c @@ -211,7 +211,7 @@ static void
[PATCH] [media] ivtv: avoid GFP_KERNEL in atomic context
ivtv_yuv_init() is used in atomic context,
so memory allocation should be done keeping that in mind.
Call graph for ivtv_yuv_init() is as follows:
- ivtv_yuv_next_free()
- ivtv_yuv_prep_frame() [ioctl handler]
- ivtv_yuv_setup_stream_frame()
- ivtv_irq_dec_data_req() - ivtv_irq_handler() [ATOMIC CONTEXT]
- ivtv_yuv_udma_stream_frame() [with mutex held]
- ivtv_write() [with mutex held]
The patch adds gfp_t argument and implements its usage according to the context.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/pci/ivtv/ivtv-fileops.c | 2 +-
drivers/media/pci/ivtv/ivtv-irq.c | 2 +-
drivers/media/pci/ivtv/ivtv-yuv.c | 16
drivers/media/pci/ivtv/ivtv-yuv.h | 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/pci/ivtv/ivtv-fileops.c
b/drivers/media/pci/ivtv/ivtv-fileops.c
index 9caffd8aa995..2e8885c245e7 100644
--- a/drivers/media/pci/ivtv/ivtv-fileops.c
+++ b/drivers/media/pci/ivtv/ivtv-fileops.c
@@ -689,7 +689,7 @@ retry:
int got_sig;
if (mode == OUT_YUV)
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_KERNEL);
mutex_unlock(itv-serialize_lock);
prepare_to_wait(itv-dma_waitq, wait,
TASK_INTERRUPTIBLE);
diff --git a/drivers/media/pci/ivtv/ivtv-irq.c
b/drivers/media/pci/ivtv/ivtv-irq.c
index 19a7c9b990a3..7a44f6b7aed4 100644
--- a/drivers/media/pci/ivtv/ivtv-irq.c
+++ b/drivers/media/pci/ivtv/ivtv-irq.c
@@ -822,7 +822,7 @@ static void ivtv_irq_dec_data_req(struct ivtv *itv)
}
else {
if (test_bit(IVTV_F_I_DEC_YUV, itv-i_flags))
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_ATOMIC);
clear_bit(IVTV_F_S_NEEDS_DATA, s-s_flags);
ivtv_queue_move(s, s-q_full, NULL, s-q_predma,
itv-dma_data_req_size);
ivtv_dma_stream_dec_prepare(s, itv-dma_data_req_offset +
IVTV_DECODER_OFFSET, 0);
diff --git a/drivers/media/pci/ivtv/ivtv-yuv.c
b/drivers/media/pci/ivtv/ivtv-yuv.c
index 2ad65eb29832..9bf47b89f8a0 100644
--- a/drivers/media/pci/ivtv/ivtv-yuv.c
+++ b/drivers/media/pci/ivtv/ivtv-yuv.c
@@ -854,7 +854,7 @@ void ivtv_yuv_work_handler(struct ivtv *itv)
yi-old_frame_info = f;
}
-static void ivtv_yuv_init(struct ivtv *itv)
+static void ivtv_yuv_init(struct ivtv *itv, gfp_t gfp)
{
struct yuv_playback_info *yi = itv-yuv_info;
@@ -936,7 +936,7 @@ static void ivtv_yuv_init(struct ivtv *itv)
}
/* We need a buffer for blanking when Y plane is offset - non-fatal if
we can't get one */
- yi-blanking_ptr = kzalloc(720 * 16, GFP_KERNEL|__GFP_NOWARN);
+ yi-blanking_ptr = kzalloc(720 * 16, gfp|__GFP_NOWARN);
if (yi-blanking_ptr) {
yi-blanking_dmaptr = pci_map_single(itv-pdev,
yi-blanking_ptr, 720*16, PCI_DMA_TODEVICE);
} else {
@@ -952,13 +952,13 @@ static void ivtv_yuv_init(struct ivtv *itv)
}
/* Get next available yuv buffer on PVR350 */
-static void ivtv_yuv_next_free(struct ivtv *itv)
+static void ivtv_yuv_next_free(struct ivtv *itv, gfp_t gfp)
{
int draw, display;
struct yuv_playback_info *yi = itv-yuv_info;
if (atomic_read(yi-next_dma_frame) == -1)
- ivtv_yuv_init(itv);
+ ivtv_yuv_init(itv, gfp);
draw = atomic_read(yi-next_fill_frame);
display = atomic_read(yi-next_dma_frame);
@@ -1119,12 +1119,12 @@ static int ivtv_yuv_udma_frame(struct ivtv *itv, struct
ivtv_dma_frame *args)
}
/* Setup frame according to V4L2 parameters */
-void ivtv_yuv_setup_stream_frame(struct ivtv *itv)
+void ivtv_yuv_setup_stream_frame(struct ivtv *itv, gfp_t gfp)
{
struct yuv_playback_info *yi = itv-yuv_info;
struct ivtv_dma_frame dma_args;
- ivtv_yuv_next_free(itv);
+ ivtv_yuv_next_free(itv, gfp);
/* Copy V4L2 parameters to an ivtv_dma_frame struct... */
dma_args.y_source = NULL;
@@ -1151,7 +1151,7 @@ int ivtv_yuv_udma_stream_frame(struct ivtv *itv, void
__user *src)
struct ivtv_dma_frame dma_args;
int res;
- ivtv_yuv_setup_stream_frame(itv);
+ ivtv_yuv_setup_stream_frame(itv, GFP_KERNEL);
/* We only need to supply source addresses for this */
dma_args.y_source = src;
@@ -1171,7 +1171,7 @@ int ivtv_yuv_prep_frame(struct ivtv *itv, struct
ivtv_dma_frame *args)
int res;
/* IVTV_DEBUG_INFO(yuv_prep_frame\n); */
- ivtv_yuv_next_free(itv);
+ ivtv_yuv_next_free(itv, GFP_KERNEL);
ivtv_yuv_setup_frame(itv, args);
/* Wait for frame DMA. Note that serialize_lock is locked,
so to allow other processes to access the driver while
diff --git
Elgato Eye TV Deluxe V2 supported?
I have an Elgato Eye TV V2 USB device USB ID 0fd9:002c which reading here https://github.com/mirrors/linux-2.6/blob/master/drivers/staging/media/as102/as102_usb_drv.h Looks like it should be supported (it looks like Devin wrote some of the code?)..it gets recognised in dmesg and indeed lsusb sees it, but no firmware is loaded (I have the required as102 files in /lib/firmware) and in effect it never 'initialises'. Has something broken since kernel 2.6 (I'm currently running 3.13.10) or did it never work? Googling around pops up a load of contradictory information whether it works or not. lsusb gives me this... lsusb -v -d 0fd9:002c Bus 002 Device 004: ID 0fd9:002c Elgato Systems GmbH EyeTV DTT Deluxe v2 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0fd9 Elgato Systems GmbH idProduct 0x002c EyeTV DTT Deluxe v2 bcdDevice1.00 iManufacturer 1 Elgato iProduct2 EyeTV DTT Dlx iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) lsusb ends Any ideas? Thanks in advance. Tony -- 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: Elgato Eye TV Deluxe V2 supported?
On Fri, Apr 25, 2014 at 2:31 PM, Another Sillyname anothersn...@googlemail.com wrote: I have an Elgato Eye TV V2 USB device USB ID 0fd9:002c which reading here https://github.com/mirrors/linux-2.6/blob/master/drivers/staging/media/as102/as102_usb_drv.h Looks like it should be supported (it looks like Devin wrote some of the code?)..it gets recognised in dmesg and indeed lsusb sees it, but no firmware is loaded (I have the required as102 files in /lib/firmware) and in effect it never 'initialises'. Hi Tony, Sorry, I saw your email yesterday but forgot to reply. The issue is that the as102 is still in staging, so it won't appear in mainline kernels by default. You would need to install the media_build tree, run make menuconfig, enable staging drivers and then enable the as102 bridge. The messages you are seeing in dmesg and lsusb are just the kernel finding the hardware at a USB level - these messages will appear whether there is a driver or not for the actual device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato Eye TV Deluxe V2 supported?
Thanks Devin Is the as102 tree ever likely to go mainline? Regards Tony On 25 April 2014 19:40, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Fri, Apr 25, 2014 at 2:31 PM, Another Sillyname anothersn...@googlemail.com wrote: I have an Elgato Eye TV V2 USB device USB ID 0fd9:002c which reading here https://github.com/mirrors/linux-2.6/blob/master/drivers/staging/media/as102/as102_usb_drv.h Looks like it should be supported (it looks like Devin wrote some of the code?)..it gets recognised in dmesg and indeed lsusb sees it, but no firmware is loaded (I have the required as102 files in /lib/firmware) and in effect it never 'initialises'. Hi Tony, Sorry, I saw your email yesterday but forgot to reply. The issue is that the as102 is still in staging, so it won't appear in mainline kernels by default. You would need to install the media_build tree, run make menuconfig, enable staging drivers and then enable the as102 bridge. The messages you are seeing in dmesg and lsusb are just the kernel finding the hardware at a USB level - these messages will appear whether there is a driver or not for the actual device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato Eye TV Deluxe V2 supported?
Is the as102 tree ever likely to go mainline? The only reason it's in staging is because it doesn't meet the coding standards (i.e. whitespace, variable naming, etc). Somebody needs to come along and expend the energy to satisfy the whitespace gods. Seems like a fantastically stupid reason to keep a working driver out of the mainline, but that's just my opinion. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Elgato Eye TV Deluxe V2 supported?
OK, I'm not a coder these days but I'll look and see if I can work it out. Regards and have a good weekend. Tony On 25 April 2014 19:54, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Is the as102 tree ever likely to go mainline? The only reason it's in staging is because it doesn't meet the coding standards (i.e. whitespace, variable naming, etc). Somebody needs to come along and expend the energy to satisfy the whitespace gods. Seems like a fantastically stupid reason to keep a working driver out of the mainline, but that's just my opinion. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, Am 24.04.2014 23:26, schrieb Mauro Carvalho Chehab: Em Thu, 24 Apr 2014 15:24:20 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: [...] What can do, instead, is to sniff the traffic at the USB port, and get the proper GPIO, XCLK and I2C speed settings for this device. My suggestion is to either run it on a QEMU VM machine, redirecting the USB device to the VM and sniffing the traffic on Linux, or to use some USB snoop software. Take a look at: http://linuxtv.org/wiki/index.php/Bus_snooping/sniffing We have a script that parses em28xx traffic, converting them into register writes. All you need to do is to sniff the traffic and check what GPIO registers are needed to reset the device. Then, add the corresponding data at em28xx-cards.c. Ok, I managed to setup a VBox with TheOtherOS and usbmon and sniffed some traffic when I (virtually) plugged in the device. The file is (compressed) about ~620 KiB. I am honest: I have no clue what I sniffed or how I should read GPIO registers from there. If anyone is interested in helping me I would send the file directly. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: [PATCH] mm: get_user_pages(write,force) refuse to COW in shared areas
On Fri, 25 Apr 2014, Oleg Nesterov wrote: And I forgot to mention, there is another reason why I would like to change uprobes to follow the same convention. I still think it would be better to kill __replace_page() and use gup(FOLL_WRITE | FORCE) in uprobe_write_opcode(). Oh, please please do! I assumed there was a good atomicity reason for doing it that way, but if you can do it with gup() please do so. I went off into a little rant about __replace_page() in my reply to you; but then felt that you had approached with an honest enquiry, and didn't deserve a rant in response, so I deleted it. And, of course, I'm conscious that I have from start to finish withheld my involvement from uprobes, and refused to review that __replace_page() (beyond insisting that it not be put in a common place for sharing with KSM, because I just couldn't guarantee it for uprobes). I'm afraid that it's much like HWPoison to me, a complexity (nastiness?) way beyond what I have time to support myself. Hugh -- 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
Help to solve compile errors in smsusb driver.
Guys, I’m trying to compile most recent Siano drivers with old kernel tree (3.4.75 linux-sunxi). The module seems compile but final linker (?) give me a few errors. smsendian_handle_tx_message is in media/common/siano/smsendian.c as expected. All tips are appreciated ;-) Thank you ! - Roberto robertoalcantara@ubuntu:/media/robertoalcantara/awsom-linux-sunxi/linux-sunxi$ ./build.sh -p awsom20 Using previous config file .config.awsom20 CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/mali/ump/../mali/linux/mali_osk_atomics.o CC [M] drivers/gpu/mali/ump/../mali/linux/mali_osk_locks.o CC [M] drivers/gpu/mali/ump/../mali/linux/mali_osk_memory.o CC [M] drivers/media/dvb/siano/smsusb.o CC [M] drivers/gpu/mali/ump/../mali/linux/mali_osk_math.o CC [M] drivers/gpu/mali/ump/../mali/linux/mali_osk_misc.o LD [M] drivers/gpu/mali/ump/ump.o Kernel: arch/arm/boot/Image is ready Building modules, stage 2. Kernel: arch/arm/boot/zImage is ready Image arch/arm/boot/uImage is ready MODPOST 138 modules ERROR: smsendian_handle_tx_message [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_registry_getmode [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: sms_board_load_modules [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_start_device [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_set_board_id [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_register_device [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: sms_get_board [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_translate_msg [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_onresponse [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smsendian_handle_rx_message [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smsendian_handle_message_header [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_getbuffer [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_unregister_device [drivers/media/dvb/siano/smsusb.ko] undefined! ERROR: smscore_putbuffer [drivers/media/dvb/siano/smsusb.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 robertoalcantara@ubuntu:/media/robertoalcantara/awsom-linux-sunxi/linux-sunxi$ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: stk1160: Avoid stack-allocated buffer for control URBs
On Apr 17, Ezequiel Garcia wrote:
Currently stk1160_read_reg() uses a stack-allocated char to get the
read control value. This is wrong because usb_control_msg() requires
a kmalloc-ed buffer.
This commit fixes such issue by kmalloc'ating a 1-byte buffer to receive
the read value.
While here, let's remove the urb_buf array which was meant for a similar
purpose, but never really used.
Cc: Alan Stern st...@rowland.harvard.edu
Reported-by: Sander Eikelenboom li...@eikelenboom.it
Ouch, I forgot to Cc Sander!
Sander, Here's the patch:
https://patchwork.linuxtv.org/patch/23660/
Maybe you can give it a ride and confirm it fixes the warning over there?
Also, have you observed any serious issues caused by this or just the
DMA API debug warning?
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/media/usb/stk1160/stk1160-core.c | 10 +-
drivers/media/usb/stk1160/stk1160.h | 1 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-core.c
b/drivers/media/usb/stk1160/stk1160-core.c
index 34a26e0..03504dc 100644
--- a/drivers/media/usb/stk1160/stk1160-core.c
+++ b/drivers/media/usb/stk1160/stk1160-core.c
@@ -67,17 +67,25 @@ int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8
*value)
{
int ret;
int pipe = usb_rcvctrlpipe(dev-udev, 0);
+ u8 *buf;
*value = 0;
+
+ buf = kmalloc(sizeof(u8), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
ret = usb_control_msg(dev-udev, pipe, 0x00,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- 0x00, reg, value, sizeof(u8), HZ);
+ 0x00, reg, buf, sizeof(u8), HZ);
if (ret 0) {
stk1160_err(read failed on reg 0x%x (%d)\n,
reg, ret);
+ kfree(buf);
return ret;
}
+ *value = *buf;
+ kfree(buf);
return 0;
}
diff --git a/drivers/media/usb/stk1160/stk1160.h
b/drivers/media/usb/stk1160/stk1160.h
index 05b05b1..abdea48 100644
--- a/drivers/media/usb/stk1160/stk1160.h
+++ b/drivers/media/usb/stk1160/stk1160.h
@@ -143,7 +143,6 @@ struct stk1160 {
int num_alt;
struct stk1160_isoc_ctl isoc_ctl;
- char urb_buf[255]; /* urb control msg buffer */
/* frame properties */
int width;/* current frame width */
--
1.9.1
--
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
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.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/RFC v3 1/5] leds: Add sysfs and kernel internal API for flash LEDs
On Fri, Apr 11, 2014 at 7:56 AM, Jacek Anaszewski
j.anaszew...@samsung.com wrote:
Some LED devices support two operation modes - torch and
flash.
Do we have a method to look up the capabilities from LED devices driver?
For example, the LED device supports Torch/Flash then LED device
driver should set a flag like LED_DEV_CAP_TORCH or LED_DEV_CAP_FLASH.
If it doesn't support those functions, it won't set those flags.
LED Flash class core can check those flags for further usage.
This patch provides support for flash LED devices
in the LED subsystem by introducing new sysfs attributes
and kernel internal interface. The attributes being
introduced are: flash_brightness, flash_strobe, flash_timeout,
max_flash_timeout, max_flash_brightness, flash_fault and
optional external_strobe, indicator_brightness and
max_indicator_btightness. All the flash related features
typo here, it should max_indicator_btightness - max_indicator_brightness
are placed in a separate module.
Please add one empty line here.
The modifications aim to be compatible with V4L2 framework
requirements related to the flash devices management. The
design assumes that V4L2 sub-device can take of the LED class
device control and communicate with it through the kernel
internal interface. When V4L2 Flash sub-device file is
opened, the LED class device sysfs interface is made
unavailable.
I don't quite understand the last sentence here. Looks like the LED
flash class interface binds to V4L2 Flash sub-device, then why we need
to export sysfs for user space if the only user is V4L2 which can talk
through kernel internal API here.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
---
drivers/leds/Kconfig|8 +
drivers/leds/Makefile |1 +
drivers/leds/led-class.c| 36 ++-
drivers/leds/led-flash.c| 627
+++
If we go for the LED Flash class, I prefer to use led-class-flash.c
rather than led-flash.c
drivers/leds/led-triggers.c | 16 +-
drivers/leds/leds.h |6 +
include/linux/leds.h| 50 +++-
include/linux/leds_flash.h | 252 +
leds_flash.h - led-class-flash.h
8 files changed, 982 insertions(+), 14 deletions(-)
create mode 100644 drivers/leds/led-flash.c
create mode 100644 include/linux/leds_flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 2062682..1e1c81f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,14 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate Flash LEDs Support
LED Flash Class Support
+ depends on LEDS_CLASS
+ help
+ This option enables support for flash LED devices. Say Y if you
+ want to use flash specific features of a LED device, if they
+ are supported.
+
This help message is not very accurate, please take a look at
LEDS_CLASS. And I prefer this driver can be a module, so it should be
mentioned here.
comment LED drivers
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3cd76db..8861b86 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index f37d63c..58f16c3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -9,15 +9,16 @@
* published by the Free Software Foundation.
*/
-#include linux/module.h
-#include linux/kernel.h
+#include linux/ctype.h
+#include linux/device.h
+#include linux/err.h
#include linux/init.h
+#include linux/kernel.h
#include linux/list.h
+#include linux/module.h
+#include linux/slab.h
#include linux/spinlock.h
-#include linux/device.h
#include linux/timer.h
-#include linux/err.h
-#include linux/ctype.h
#include linux/leds.h
#include leds.h
I believe this change is kind of cleanup, could you please split them
out? For this patch we just need add those LED Flash class related
code.
@@ -45,28 +46,38 @@ static ssize_t brightness_store(struct device *dev,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
unsigned long state;
- ssize_t ret = -EINVAL;
+ ssize_t ret;
+
+ mutex_lock(led_cdev-led_lock);
+
+ if (led_sysfs_is_locked(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
ret = kstrtoul(buf, 10, state);
if (ret)
-
