Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote: On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil hverk...@xs4all.nl wrote: But the driver has that information, so it should act accordingly. So on first open you can check whether the current input has a tuner and power on the tuner in that case. On S_INPUT you can also poweron/off accordingly (bit iffy against the spec, though). So in that case the first use case would actually work. It does require that tuner-core.c supports s_power(1), of course. This will get messy, and is almost certain to get screwed up and cause regressions at least on some devices. I don't see why this should be messy. Anyway, this is all theoretical as long as tuner-core doesn't support s_power(1). Let's get that in first. BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner when called. I think it should be added, even though most (all?) tuners will need time before they can return anything sensible. Bear in mind that some tuners can take several seconds to load firmware when powered up. You don't want a situation where the tuner is reloading firmware continuously, the net result being that calls to v4l2-ctl that used to take milliseconds now take multiple seconds. Yes, but calling VIDIOC_G_TUNER is a good time to wake up the tuner :-) BTW2: it's not a good idea to just broadcast s_power to all subdevs. That should be done to the tuner(s) only since other subdevs might also implement s_power. For now it's pretty much just tuners and some sensors, though. You know, this really needs to be a standardized module option and/or sysfs entry: 'always on', 'wake up on first open', 'wake up on first use'. That would definitely be useful, but it shouldn't be a module option since you can have multiple devices using the same module. Of course, I forgot about that. It really should be an addition to the V4L API. This would actually for once be a good use of sysfs. Regards, Hans -- 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: no mmu on videobuf2
2011/6/16 Marek Szyprowski m.szyprow...@samsung.com: Hello Scott, Hi Marek and Laurent, I am working on v4l2 drivers for blackfin which is a no mmu soc. I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2. But __setup_offsets() use plane offset to fill m.offset, which is always 0 for single-planar buffer. So pgoff in get_unmapped_area callback equals 0. I only found uvc handled get_unmapped_area for no mmu system, but it manages buffers itself. I really want videobuf2 to manage buffers. Please give me some advice. I'm not really sure if I know the differences between mmu and no-mmu systems (from the device driver perspective). I assume that you are using videobuf2-vmalloc allocator. Note that memory allocators/managers are well separated from the videobuf2 logic. If it the current one doesn't serve you well you can make your own no-mmu allocator. Later once we identify all differences it might be merged with the standard one or left alone if the merge is not really possible or easy. Best regards -- Marek Szyprowski Samsung Poland RD Center Hi Marek, I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. Regards, Scott -- 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: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Thursday 16 June 2011 02:48:12 Philip Balister wrote: On 06/15/2011 12:37 AM, Arnd Bergmann wrote: On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote: I see your concerns, but I really wonder how to determine the properties of the global/default cma pool. You definitely don't want to give all available memory o CMA, because it will have negative impact on kernel operation (kernel really needs to allocate unmovable pages from time to time). Exactly. This is a hard problem, so I would prefer to see a solution for coming up with reasonable defaults. Is this a situation where passing the information from device tree might help? I know this does not help short term, but I am trying to understand the sorts of problems device tree can help solve. The device tree is a good place to describe any hardware properties such as 'this device will need 32 MB of contiguous allocations on the memory bank described in that other device node'. It is however not a good place to describe user settings such as 'I want to give this device a 200 MB pool for large allocations so I can run application X efficiently', because that would require knowledge in the boot loader about local policy, which it should generally not care about. Arnd -- 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
DVB_NET help message is useless
Hi, I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see what's that by asking with '?'. And I got this crap: CONFIG_DVB_NET: The DVB network support in the DVB core can optionally be disabled if this option is set to N. If unsure say Y. Why do you think this help message is useful? It's clear to everybody that if one eventually disables it it will be disabled. The help message should mention _what_ the network support is. I would send a patch, but I really have no idea what's that good for. thanks, -- js -- 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: no mmu on videobuf2
2011/6/16 Scott Jiang scott.jiang.li...@gmail.com: 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com: Hello Scott, Hi Marek and Laurent, I am working on v4l2 drivers for blackfin which is a no mmu soc. I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2. But __setup_offsets() use plane offset to fill m.offset, which is always 0 for single-planar buffer. So pgoff in get_unmapped_area callback equals 0. I only found uvc handled get_unmapped_area for no mmu system, but it manages buffers itself. I really want videobuf2 to manage buffers. Please give me some advice. I'm not really sure if I know the differences between mmu and no-mmu systems (from the device driver perspective). I assume that you are using videobuf2-vmalloc allocator. Note that memory allocators/managers are well separated from the videobuf2 logic. If it the current one doesn't serve you well you can make your own no-mmu allocator. Later once we identify all differences it might be merged with the standard one or left alone if the merge is not really possible or easy. Best regards -- Marek Szyprowski Samsung Poland RD Center Hi Marek, I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. hi, Scott if it is single plane, surely the offset is 0 for plane 0 what do you mean the actual addr ? __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. are you using soc_camera ? you can add your get_unmapped_area in soc_camera. if not, you can add it in your v4l2_file_operations ops, while still using videbuf2 to management your buffer. Regards, Scott -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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: no mmu on videobuf2
Hi Kassey, 2011/6/16 Kassey Lee kassey1...@gmail.com: 2011/6/16 Scott Jiang scott.jiang.li...@gmail.com: 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com: Hello Scott, Hi Marek and Laurent, I am working on v4l2 drivers for blackfin which is a no mmu soc. I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2. But __setup_offsets() use plane offset to fill m.offset, which is always 0 for single-planar buffer. So pgoff in get_unmapped_area callback equals 0. I only found uvc handled get_unmapped_area for no mmu system, but it manages buffers itself. I really want videobuf2 to manage buffers. Please give me some advice. I'm not really sure if I know the differences between mmu and no-mmu systems (from the device driver perspective). I assume that you are using videobuf2-vmalloc allocator. Note that memory allocators/managers are well separated from the videobuf2 logic. If it the current one doesn't serve you well you can make your own no-mmu allocator. Later once we identify all differences it might be merged with the standard one or left alone if the merge is not really possible or easy. Best regards -- Marek Szyprowski Samsung Poland RD Center Hi Marek, I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. hi, Scott if it is single plane, surely the offset is 0 for plane 0 yes, it is absolutely right. what do you mean the actual addr ? I should return virtual address of the buffer in get_unmapped_area callback. __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. are you using soc_camera ? you can add your get_unmapped_area in soc_camera. if not, you can add it in your v4l2_file_operations ops, while still using videbuf2 to management your buffer. yes, I have added this method, just copy __find_plane_by_offset code. But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap. These two operations are called by one system call, so they should have a uniform looks. Regards, Scott -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB_NET help message is useless
On Thursday 16 June 2011 09:06:59 Jiri Slaby wrote: I would send a patch, but I really have no idea what's that good for. DVB network support is referring to the IP stack. This option is set to N when compiling the Linux DVB stack on systems without IP networking. Please submit a patch if you need a better description. --HPS -- 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: uvcvideo failure under xHCI
Hi Sarah, On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote: On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote: When I plug in a webcam under an xHCI host controller in 3.0-rc3+ (basically top of Greg's usb-linus branch) with xHCI debugging turned on, the host controller occasionally cannot keep up with the isochronous transfers, and it tells the xHCI driver that it had to skip several microframes of transfers. These Missed Service Intervals aren't supposed to be fatal errors, just an indication that something was hogging the PCI memory bandwidth. The xHCI driver then sets the URB's status to -EXDEV, to indicate that some of the iso_frame_desc transferred, and sets at least one frame's status to -EXDEV: ... The urb-status causes uvcvideo code in uvc_status.c:uvc_status_complete() to fail with the message: Jun 15 17:37:11 talon kernel: [ 117.987769] uvcvideo: Non-zero status (-18) in video completion handler. ... I've grepped through drivers/media/video, and it seems like none of the drivers handle the -EXDEV status. What should the xHCI driver be setting the URB's status and frame status to when the xHCI host controller skips over transfers? -EREMOTEIO? Or does it need to set the URB's status to zero, but only set the individual frame status to -EXDEV? Ok, looking at both EHCI and UHCI, they seem to set the urb-status to zero, regardless of what they set the frame descriptor field to. Alan, does that seem correct? According to Documentation/usb/error-codes.txt, host controller drivers should set the status to -EXDEV. However, no device drivers seem to handle that, probably because the EHCI/UHCI drivers don't use that error code. Drivers are clearly out of sync with the documentation, so we should fix one of them. I've created a patch to do the same thing in the xHCI driver, and I seem to be getting consistent video with xHCI debugging turned on, despite lots of Missed Service Interval events. -- 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
RTL2831U wont compile against 2.6.38
Hi there, I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel (2.6.38) and failed. The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the rc coding seem have to changed a lot since it got touched the last time. The hg respository ~anttip/rtl2831u wont compile as well, since its even older. The recent git respositories for media_tree and anttip dont contain drivers for the rtl2831u. Has this device been abandoned, or is anyone working on it? greetings, Thomas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: no mmu on videobuf2
Hello, On Thursday, June 16, 2011 9:57 AM Scott Jiang wrote: (snipped) I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. hi, Scott if it is single plane, surely the offset is 0 for plane 0 yes, it is absolutely right. what do you mean the actual addr ? I should return virtual address of the buffer in get_unmapped_area callback. __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. are you using soc_camera ? you can add your get_unmapped_area in soc_camera. if not, you can add it in your v4l2_file_operations ops, while still using videbuf2 to management your buffer. yes, I have added this method, just copy __find_plane_by_offset code. But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap. These two operations are called by one system call, so they should have a uniform looks. If videobuf2-core and its memory allocator interface lacks some operations that are essential for no-mmu systems, please just add them. Frankly I have no experience with Linux no-mmu systems, so I might have missed something that is required for no-mmu case. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: no mmu on videobuf2
Hi Scott, On Thursday 16 June 2011 09:57:05 Scott Jiang wrote: 2011/6/16 Kassey Lee kassey1...@gmail.com: 2011/6/16 Scott Jiang scott.jiang.li...@gmail.com: 2011/6/16 Marek Szyprowski m.szyprow...@samsung.com: Hi Marek and Laurent, I am working on v4l2 drivers for blackfin which is a no mmu soc. I found videobuf allocate memory in mmap not reqbuf, so I turn to videobuf2. But __setup_offsets() use plane offset to fill m.offset, which is always 0 for single-planar buffer. So pgoff in get_unmapped_area callback equals 0. I only found uvc handled get_unmapped_area for no mmu system, but it manages buffers itself. I really want videobuf2 to manage buffers. Please give me some advice. I'm not really sure if I know the differences between mmu and no-mmu systems (from the device driver perspective). I assume that you are using videobuf2-vmalloc allocator. Note that memory allocators/managers are well separated from the videobuf2 logic. If it the current one doesn't serve you well you can make your own no-mmu allocator. Later once we identify all differences it might be merged with the standard one or left alone if the merge is not really possible or easy. I used dma-contig allocator. I mean if offset is 0, I must get actual addr from this offset. if it is single plane, surely the offset is 0 for plane 0 yes, it is absolutely right. what do you mean the actual addr ? I should return virtual address of the buffer in get_unmapped_area callback. __find_plane_by_offset can do this. But it is an internal function. I think there should be a function called vb2_get_unmapped_area to do this in framework side. are you using soc_camera ? you can add your get_unmapped_area in soc_camera. if not, you can add it in your v4l2_file_operations ops, while still using videbuf2 to management your buffer. yes, I have added this method, just copy __find_plane_by_offset code. But it is ugly, it should have a vb2_get_unmapped_area like vb2_mmap. These two operations are called by one system call, so they should have a uniform looks. I agree with that. get_unmapped_area is a file operation and should be implemented using a videobuf2 helper, like vb2_mmap. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: Don't access media entity after is has been destroyed
On Wednesday, June 15, 2011 10:36:26 Laurent Pinchart wrote: Entities associated with video device nodes are unregistered in video_unregister_device(). This destroys the entity even though it can still be accessed through open video device nodes. Move the media_device_unregister_entity() call from video_unregister_device() to v4l2_device_release() to ensure that the entity isn't unregistered until the last reference to the video device is released. Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those functions were designed for subdevs, to avoid a parent module from being removed while still accessible through board code. They're not currently needed for video device nodes, and will oops when a hotpluggable device is disconnected during streaming, as media_entity_put() called in v4l2_device_release() tries to access entity-parent-dev-driver which is set to NULL when the device is disconnected. Looks good. Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/video/v4l2-dev.c | 36 +++- 1 files changed, 7 insertions(+), 29 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 19d5ae2..5dc1fa1 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -167,6 +167,12 @@ static void v4l2_device_release(struct device *cd) mutex_unlock(videodev_lock); +#if defined(CONFIG_MEDIA_CONTROLLER) + if (vdev-v4l2_dev vdev-v4l2_dev-mdev + vdev-vfl_type != VFL_TYPE_SUBDEV) + media_device_unregister_entity(vdev-entity); +#endif + /* Release video_device and perform other cleanups as needed. */ vdev-release(vdev); @@ -405,17 +411,6 @@ static int v4l2_open(struct inode *inode, struct file *filp) /* and increase the device refcount */ video_get(vdev); mutex_unlock(videodev_lock); -#if defined(CONFIG_MEDIA_CONTROLLER) - if (vdev-v4l2_dev vdev-v4l2_dev-mdev - vdev-vfl_type != VFL_TYPE_SUBDEV) { - entity = media_entity_get(vdev-entity); - if (!entity) { - ret = -EBUSY; - video_put(vdev); - return ret; - } - } -#endif if (vdev-fops-open) { if (vdev-lock mutex_lock_interruptible(vdev-lock)) { ret = -ERESTARTSYS; @@ -431,14 +426,8 @@ static int v4l2_open(struct inode *inode, struct file *filp) err: /* decrease the refcount in case of an error */ - if (ret) { -#if defined(CONFIG_MEDIA_CONTROLLER) - if (vdev-v4l2_dev vdev-v4l2_dev-mdev - vdev-vfl_type != VFL_TYPE_SUBDEV) - media_entity_put(entity); -#endif + if (ret) video_put(vdev); - } return ret; } @@ -455,11 +444,6 @@ static int v4l2_release(struct inode *inode, struct file *filp) if (vdev-lock) mutex_unlock(vdev-lock); } -#if defined(CONFIG_MEDIA_CONTROLLER) - if (vdev-v4l2_dev vdev-v4l2_dev-mdev - vdev-vfl_type != VFL_TYPE_SUBDEV) - media_entity_put(vdev-entity); -#endif /* decrease the refcount unconditionally since the release() return value is ignored. */ video_put(vdev); @@ -754,12 +738,6 @@ void video_unregister_device(struct video_device *vdev) if (!vdev || !video_is_registered(vdev)) return; -#if defined(CONFIG_MEDIA_CONTROLLER) - if (vdev-v4l2_dev vdev-v4l2_dev-mdev - vdev-vfl_type != VFL_TYPE_SUBDEV) - media_device_unregister_entity(vdev-entity); -#endif - mutex_lock(videodev_lock); /* This must be in a critical section to prevent a race with v4l2_open. * Once this bit has been cleared video_get may never be called again. -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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.0] OMAP3 ISP and media controller fixes
Hi Mauro, The following changes since commit 2c53b436a30867eb6b47dd7bab23ba638d1fb0d2: Linux 3.0-rc3 (2011-06-13 15:29:59 -0700) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-stable-omap3isp Laurent Pinchart (1): v4l: Don't access media entity after is has been destroyed Ohad Ben-Cohen (1): media: omap3isp: fix a potential NULL deref drivers/media/video/omap3isp/isp.c |2 +- drivers/media/video/v4l2-dev.c | 39 ++- 2 files changed, 8 insertions(+), 33 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo failure under xHCI
Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Hi Laurent, I think this issue has been happening for a while now, but my recent patches to remove most of the xHCI debugging have finally allowed me to use a webcam under xHCI with debugging on. Unfortunately, it doesn't work very well. When I plug in a webcam under an xHCI host controller in 3.0-rc3+ (basically top of Greg's usb-linus branch) with xHCI debugging turned on, the host controller occasionally cannot keep up with the isochronous transfers, and it tells the xHCI driver that it had to skip several microframes of transfers. These Missed Service Intervals aren't supposed to be fatal errors, just an indication that something was hogging the PCI memory bandwidth. The xHCI driver then sets the URB's status to -EXDEV, to indicate that some of the iso_frame_desc transferred, and sets at least one frame's status to -EXDEV: static int skip_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td, struct xhci_transfer_event *event, struct xhci_virt_ep *ep, int *status) { struct xhci_ring *ep_ring; struct urb_priv *urb_priv; struct usb_iso_packet_descriptor *frame; int idx; ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event-buffer)); urb_priv = td-urb-hcpriv; idx = urb_priv-td_cnt; frame = td-urb-iso_frame_desc[idx]; /* The transfer is partly done */ *status = -EXDEV; frame-status = -EXDEV; /* calc actual length */ frame-actual_length = 0; /* Update ring dequeue pointer */ while (ep_ring-dequeue != td-last_trb) inc_deq(xhci, ep_ring, false); inc_deq(xhci, ep_ring, false); return finish_td(xhci, td, NULL, event, ep, status, true); } The urb-status causes uvcvideo code in uvc_status.c:uvc_status_complete() to fail with the message: Jun 15 17:37:11 talon kernel: [ 117.987769] uvcvideo: Non-zero status (-18) in video completion handler. It doesn't resubmit the isochronous URB in that case, and the userspace video freezes. If I restart the application, the video comes back until the next Missed Service Interval event from the xHCI driver. Ideally, the video driver would just resubmit the URB, and the xHCI host controller would complete transfers as best it can. I think the frames with -EXDEV status should be treated like short transfers. I've grepped through drivers/media/video, and it seems like none of the drivers handle the -EXDEV status. What should the xHCI driver be setting the URB's status and frame status to when the xHCI host controller skips over transfers? -EREMOTEIO? Or does it need to set the URB's status to zero, but only set the individual frame status to -EXDEV? Sarah Sharp -- 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 Video drivers don't handle EXDEV probably because it is an error code about filesystem links: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03 Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB_NET help message is useless
Em 16-06-2011 04:06, Jiri Slaby escreveu: Hi, I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see what's that by asking with '?'. And I got this crap: CONFIG_DVB_NET: The DVB network support in the DVB core can optionally be disabled if this option is set to N. If unsure say Y. Why do you think this help message is useful? It's clear to everybody that if one eventually disables it it will be disabled. The help message should mention _what_ the network support is. I would send a patch, but I really have no idea what's that good for. As Hans answered this option disables the IP stack from the DVB driver. The IP stack is part of the DVB standard. It is used, for example, by automatic firmware updates used on STB's. It can also be used to access the Internet, via the DVB card, if the network provider supports it. Before 3.0, this were enabled on all cards. However, if the IP stack is disabled, this would mean that the entire DVB would also be disabled. So, this option were added. It may make sense to make it dependent of CONFIG_EMBEDDED, as normal users should not need to disable it. Feel free to send us a patch if you want to improve the Kconfig logic or help message. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dual sveon stv22 Afatech af9015 support (kworld clone)
Hello again: The output for lsusb -vvd 1b80:e401 is: Bus 001 Device 016: ID 1b80:e401 Afatech Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1b80 Afatech idProduct 0xe401 bcdDevice 2.00 iManufacturer 1 AG Sistemas Informaticos iProduct 2 SVEON STV22 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x (Bus Powered) --- now i'm working in the remote controller keytable, i'm looking for the remote because i forgot where i put it but i expect to find it soon. thanks for all Emilio David Diaus López
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Em 16-06-2011 03:21, Hans Verkuil escreveu: On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote: On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil hverk...@xs4all.nl wrote: But the driver has that information, so it should act accordingly. So on first open you can check whether the current input has a tuner and power on the tuner in that case. On S_INPUT you can also poweron/off accordingly (bit iffy against the spec, though). So in that case the first use case would actually work. It does require that tuner-core.c supports s_power(1), of course. This will get messy, and is almost certain to get screwed up and cause regressions at least on some devices. I don't see why this should be messy. Anyway, this is all theoretical as long as tuner-core doesn't support s_power(1). Let's get that in first. Adding s_power to tuner-core is the easiest part. The hardest one is to decide what would be the proper behaviour. See bellow. BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner when called. I think it should be added, even though most (all?) tuners will need time before they can return anything sensible. Bear in mind that some tuners can take several seconds to load firmware when powered up. You don't want a situation where the tuner is reloading firmware continuously, the net result being that calls to v4l2-ctl that used to take milliseconds now take multiple seconds. The question is not when to wake up the tuner, but when to put it to sleep. Really, the big issue is on USB devices, where we don't want to spend lots of power while the device is not active. Some devices even become hot when the tuner is not sleeping. As Devin pointed, some devices like tm6000 take about 30-45 seconds for loading a firmware (ok, it is a broken design. We should not take it as a good example). Currently, there's no way to know when a radio device is being used or not. Even for video, scripts that call v4l-ctl or v4l2-ctl and then start some userspace application are there for years. We have even an example for that at the v4l-utils: contrib/v4l_rec.pl. One possible logic that would solve the scripting would be to use a watchdog to monitor ioctl activities. If not used for a while, it could send a s_power to put the device to sleep, but this may not solve all our problems. So, I agree with Devin: we need to add an option to explicitly control the power management logic of the device, having 3 modes of operation: POWER_AUTO - use the watchdogs to poweroff POWER_ON - explicitly powers on whatever subdevices are needed in order to make the V4L ready to stream; POWER_OFF - Put all subdevices to power-off if they support it. After implementing such logic, and keeping the default as POWER_ON, we may announce that the default will change to POWER_AUTO, and give some time for userspace apps/scripts that need to use a different mode to change their behaviour. That means that, for example, radio -qf will need to change to POWER_ON mode, and radio -m should call POWER_OFF. It would be good if the API would also provide a way to warn userspace that a given device supports it or not (maybe at VIDIOC_QUERYCTL?). I think that such API can be implemented as a new V4L control. Yes, but calling VIDIOC_G_TUNER is a good time to wake up the tuner :-) Not really. Several popular devices load firmware based on the standard (the ones based on xc2028/xc3028/xc4000). So, before sending any tuner command, a VIDIOC_S_STD is needed. BTW2: it's not a good idea to just broadcast s_power to all subdevs. That should be done to the tuner(s) only since other subdevs might also implement s_power. For now it's pretty much just tuners and some sensors, though. You know, this really needs to be a standardized module option and/or sysfs entry: 'always on', 'wake up on first open', 'wake up on first use'. That would definitely be useful, but it shouldn't be a module option since you can have multiple devices using the same module. Of course, I forgot about that. It really should be an addition to the V4L API. This would actually for once be a good use of sysfs. Regards, Hans -- 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: RTL2831U wont compile against 2.6.38
Thomas Holzeisen wrote: Hi there, I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel (2.6.38) and failed. The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the rc coding seem have to changed a lot since it got touched the last time. The hg respository ~anttip/rtl2831u wont compile as well, since its even older. The recent git respositories for media_tree and anttip dont contain drivers for the rtl2831u. Has this device been abandoned, or is anyone working on it? greetings, Thomas There are still people working on it and there is new sources, e.g. look at http://www.spinics.net/lists/linux-media/msg24890.html at the very bottom. Worked like a charm at my system with kernel 2.6.39. I think, there will be announcements later at http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start Greetings from Braunschweig, Germany. Sascha -- 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: Some fixes for alsa_stream
Hi, On 06/15/2011 05:45 PM, Mauro Carvalho Chehab wrote: snip 1) try to find a common buffer size that are acceptable by both drivers, as using the same buffer size helps to avoid memcpy's, especially if mmap mode is enabled; This is not needed, using the same buffer size does nothing to avoid memcpy's there are 2 possible scenarios: 1) Use read() + write() like we do now, this means 2 memcpy's in the form of copy_to_user to our buffer followed by a copy_from_user, and we don't need to care about buffer sizes, we just write the amount of samples we managed to read. 2) Properly implemented mmap, in this case we need to do a regular memcpy in userspace from the mmap-ed capture buffers to the mmapped playback buffers. In this case having indentical buffersizes would simplify the code, as it avoids the need to split the memcpy into multiple memcpy's when crossing a buffer boundary. But we need to handle this case anyways in case we cannot find a shared period size. More over mmap mode is a pain and just not worth it IMHO. 2) If the buffer size means that the latency will be more than a reasonable time interval [1], then fall back to use different periods; It is better to just aim for the optimal period size right away, this greatly simplifies the code, as said before trying to get identical buffer sizes is premature optimization IMHO. xawtv barely registers in top on my machine and this includes copying over the actual video data from /dev/video# to shared memory xv pixmaps. If that part does not even register imagine how little CPU the audio part is using. There is no need to make the code more complicated for some theoretical performance gain here, instead we should KISS. Note that I've just pushed a patch set which includes rewritten period / buf size negotiation and a bunch of cleanups in general. This removes over 150 lines of code, while at the same time making the code more flexible. It should now work with pretty much any combination of input / output device (tested with a bt878 input and intel hda, usb-audio or pulseaudio output). I've also changed the default -alsa-pb value to default as we should not be picking something else then the user / distro configured defaults for output IMHO. The user can set a generic default in alsarc, and override that on the cmdline if he/she wants, but unless overridden on the cmdline we should respect the users generic default as specified in his alsarc. We could consider making the desired latency configurable, currently I've hardcoded it to 30 ms (was 38 with the old code on my system) note that I've chosen to specify the latency in ms rather then in a number of samples, since it should be samplerate independent IMO. Regards, Hans -- 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: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Thu, Jun 16, 2011 at 7:14 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: One possible logic that would solve the scripting would be to use a watchdog to monitor ioctl activities. If not used for a while, it could send a s_power to put the device to sleep, but this may not solve all our problems. So, I agree with Devin: we need to add an option to explicitly control the power management logic of the device, having 3 modes of operation: POWER_AUTO - use the watchdogs to poweroff POWER_ON - explicitly powers on whatever subdevices are needed in order to make the V4L ready to stream; POWER_OFF - Put all subdevices to power-off if they support it. After implementing such logic, and keeping the default as POWER_ON, we may announce that the default will change to POWER_AUTO, and give some time for userspace apps/scripts that need to use a different mode to change their behaviour. That means that, for example, radio -qf will need to change to POWER_ON mode, and radio -m should call POWER_OFF. I've considered this idea before, and it's not bad in theory. The one thing you will definitely have to watch out for is causing a race between DVB and V4L for hybrid tuners. In other words, you can have a user switching from analog to digital and you don't want the tuner to get powered down a few seconds after they started streaming video from DVB. Any such solution would have to take the above into account. We've got a history of race conditions like this and I definitely don't want to see a new one introduced. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] DocBook: Use base64 for gif/png files
On Thu, Jun 16, 2011 at 11:15:19AM -0300, Mauro Carvalho Chehab wrote: The patch utility doesn't work with non-binary files. This causes some tools to break, like generating tarball targets and the scripts that generate diff patches at http://www.kernel.org/pub/linux/kernel/v2.6/. So, let's convert all binaries to ascii using base64, and add a logic at Makefile to convert them back into binaries at runtime. Given that all the gifs are not just relatively trivial, but also things that looks like they originated or at least should as vector graphics I'd recommend to replace them by SVG files. These also have the benefit of actually beeing practically patchable. -- 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] usbvision: remove (broken) image format conversion
Hi, On 06/11/2011 02:13 PM, Mauro Carvalho Chehab wrote: Hi Hans de G., Em 26-04-2011 08:54, Hans de Goede escreveu: If you could give it a shot that would be great. I've some hardware to test this with (although I've never actually tested that hardware), so I can hopefully pick things up if you cannot finish things before you need to return the hardware. As Ondrej couldn't work on that while he was with the hardware, could you please try to address this issue? I've put it on my to do list, not sure when I'll get around to it though. Regards, Hans -- 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] [media] DocBook: Use base64 for gif/png files
Em 16-06-2011 11:25, Christoph Hellwig escreveu: On Thu, Jun 16, 2011 at 11:15:19AM -0300, Mauro Carvalho Chehab wrote: The patch utility doesn't work with non-binary files. This causes some tools to break, like generating tarball targets and the scripts that generate diff patches at http://www.kernel.org/pub/linux/kernel/v2.6/. So, let's convert all binaries to ascii using base64, and add a logic at Makefile to convert them back into binaries at runtime. Given that all the gifs are not just relatively trivial, but also things that looks like they originated or at least should as vector graphics I'd recommend to replace them by SVG files. These also have the benefit of actually beeing practically patchable. This is a good idea, but it would require to re-draw everything, as we don't have those files vectorized (I might have one or two svg files on an older tree, as I had to re-generate some graphics that used to be just pdf). One of the reasons why SVG was not used in the past is that there used to have a target to generate pdf files, and I think that the DocBook tools available on that time weren't capable of working with svg. Not sure if xmlto currently supports it, but, as we've removed the pdf generation for the media API, changing them to svg is ok. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo failure under xHCI
On Thu, 16 Jun 2011, Laurent Pinchart wrote: Hi Sarah, On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote: On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote: When I plug in a webcam under an xHCI host controller in 3.0-rc3+ (basically top of Greg's usb-linus branch) with xHCI debugging turned on, the host controller occasionally cannot keep up with the isochronous transfers, and it tells the xHCI driver that it had to skip several microframes of transfers. These Missed Service Intervals aren't supposed to be fatal errors, just an indication that something was hogging the PCI memory bandwidth. The xHCI driver then sets the URB's status to -EXDEV, to indicate that some of the iso_frame_desc transferred, and sets at least one frame's status to -EXDEV: ... The urb-status causes uvcvideo code in uvc_status.c:uvc_status_complete() to fail with the message: Jun 15 17:37:11 talon kernel: [ 117.987769] uvcvideo: Non-zero status (-18) in video completion handler. ... I've grepped through drivers/media/video, and it seems like none of the drivers handle the -EXDEV status. What should the xHCI driver be setting the URB's status and frame status to when the xHCI host controller skips over transfers? -EREMOTEIO? Or does it need to set the URB's status to zero, but only set the individual frame status to -EXDEV? Ok, looking at both EHCI and UHCI, they seem to set the urb-status to zero, regardless of what they set the frame descriptor field to. Alan, does that seem correct? The description of the behavior of ehci-hcd and uhci-hcd is correct. ohci-hcd behaves the same way too. And they all agree with the behavior described in the kerneldoc for struct urb in include/linux/usb.h. According to Documentation/usb/error-codes.txt, host controller drivers should set the status to -EXDEV. However, no device drivers seem to handle that, probably because the EHCI/UHCI drivers don't use that error code. Drivers are clearly out of sync with the documentation, so we should fix one of them. Under the circumstances, the documentation file should be changed. Sarah, can you do that along with the change to xhci-hcd? Alan Stern -- 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: Some fixes for alsa_stream
Em 16-06-2011 09:29, Hans de Goede escreveu: Hi, On 06/15/2011 05:45 PM, Mauro Carvalho Chehab wrote: snip 1) try to find a common buffer size that are acceptable by both drivers, as using the same buffer size helps to avoid memcpy's, especially if mmap mode is enabled; This is not needed, using the same buffer size does nothing to avoid memcpy's there are 2 possible scenarios: 1) Use read() + write() like we do now, this means 2 memcpy's in the form of copy_to_user to our buffer followed by a copy_from_user, and we don't need to care about buffer sizes, we just write the amount of samples we managed to read. 2) Properly implemented mmap, in this case we need to do a regular memcpy in userspace from the mmap-ed capture buffers to the mmapped playback buffers. In this case having indentical buffersizes would simplify the code, as it avoids the need to split the memcpy into multiple memcpy's when crossing a buffer boundary. But we need to handle this case anyways in case we cannot find a shared period size. More over mmap mode is a pain and just not worth it IMHO. 2) If the buffer size means that the latency will be more than a reasonable time interval [1], then fall back to use different periods; It is better to just aim for the optimal period size right away, this greatly simplifies the code, as said before trying to get identical buffer sizes is premature optimization IMHO. xawtv barely registers in top on my machine and this includes copying over the actual video data from /dev/video# to shared memory xv pixmaps. If that part does not even register imagine how little CPU the audio part is using. There is no need to make the code more complicated for some theoretical performance gain here, instead we should KISS. xawtv has an option to use zerocopy, if the X11 v4l driver is loaded and if the display adapter supports the old overlay mode. It works fine with a bttv or saa7134 board with an older Nvidia hardware, like FX-5200. This works also with older ATI hardware. I intend to make v4l Xorg driver to work with newer display adapters using texture, but I didn't have time for it yet. It would be good if we could do the same for the mmap mode for audio as well, but I don't think this has a top priority. Note that I've just pushed a patch set which includes rewritten period / buf size negotiation and a bunch of cleanups in general. This removes over 150 lines of code, while at the same time making the code more flexible. You removed mmap support, but you didn't removed the alsa-mmap option at xawtv. It should now work with pretty much any combination of input / output device (tested with a bt878 input and intel hda, usb-audio or pulseaudio output). I'll run some tests later with the boards I have here. I've also changed the default -alsa-pb value to default as we should not be picking something else then the user / distro configured defaults for output IMHO. The user can set a generic default in alsarc, and override that on the cmdline if he/she wants, but unless overridden on the cmdline we should respect the users generic default as specified in his alsarc. While pulseaudio refuses to work via ssh, this is actually a very bad idea. Xawtv is used by developers to test their stuff, and they generally do it on a remote machine, with the console captured via tty port, in order to be able to catch panic messages. For now, please revert this patch. After having pulseaudio fixed to properly handle the audio group, I'm ok to re-add it. We could consider making the desired latency configurable, currently I've hardcoded it to 30 ms (was 38 with the old code on my system) note that I've chosen to specify the latency in ms rather then in a number of samples, since it should be samplerate independent IMO. Yeah, having latency configurable sounds a good idea to me. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some fixes for alsa_stream
Hi, On 06/16/2011 04:38 PM, Mauro Carvalho Chehab wrote: Em 16-06-2011 09:29, Hans de Goede escreveu: snip Note that I've just pushed a patch set which includes rewritten period / buf size negotiation and a bunch of cleanups in general. This removes over 150 lines of code, while at the same time making the code more flexible. You removed mmap support, but you didn't removed the alsa-mmap option at xawtv. Ah, fixed. It should now work with pretty much any combination of input / output device (tested with a bt878 input and intel hda, usb-audio or pulseaudio output). I'll run some tests later with the boards I have here. Thanks. I've also changed the default -alsa-pb value to default as we should not be picking something else then the user / distro configured defaults for output IMHO. The user can set a generic default in alsarc, and override that on the cmdline if he/she wants, but unless overridden on the cmdline we should respect the users generic default as specified in his alsarc. While pulseaudio refuses to work via ssh, this is actually a very bad idea. Xawtv is used by developers to test their stuff, and they generally do it on a remote machine, with the console captured via tty port, in order to be able to catch panic messages. I'm sure developers are quite capable of creating either an .alsarc, pass the cmdline option, or change pulseaudio's config to accept non local console connections. We should try to have sane user oriented defaults, not developer oriented defaults. Also not all developers work the same way you do, so having a certain default just so it matches your work flow also is a bad idea IMHO. For now, please revert this patch. After having pulseaudio fixed to properly handle the audio group, I'm ok to re-add it. We could consider making the desired latency configurable, currently I've hardcoded it to 30 ms (was 38 with the old code on my system) note that I've chosen to specify the latency in ms rather then in a number of samples, since it should be samplerate independent IMO. Yeah, having latency configurable sounds a good idea to me. Done. Regards, Hans -- 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 8/8] marvell-cam: Basic working MMP camera driver
On Thu, 16 Jun 2011 10:37:37 +0800 Kassey Lee kassey1...@gmail.com wrote: +static void mmpcam_power_down(struct mcam_camera *mcam) +{ + struct mmp_camera *cam = mcam_to_cam(mcam); + struct mmp_camera_platform_data *pdata; +/* + * Turn off clocks and set reset lines + */ + iowrite32(0, cam-power_regs + REG_CCIC_DCGCR); + iowrite32(0, cam-power_regs + REG_CCIC_CRCR); +/* + * Shut down the sensor. + */ + pdata = cam-pdev-dev.platform_data; + gpio_set_value(pdata-sensor_power_gpio, 0); + gpio_set_value(pdata-sensor_reset_gpio, 0); it is better to have a callback function to controller sensor power on/off. and place the callback function in board.c This is an interesting question, actually. The problem is that board files are on their way out; it's going to be very hard to get any more board files into the mainline going forward. The mmp-camera driver does depend on a board file, but I've been careful to restrict things to basic platform data which can just as easily be put into a device tree. Power management callbacks don't really qualify. So it seems that we need to figure out a way to push this kind of pin/power management down into the sensor-specific code. Looking at the subdev stuff, it looks like a bit of thought has been put into that direction; there's the s_io_pin_config() callback to describe pins to the sensor. But it's almost entirely unused. There is no power up/down callback, currently. We could ponder on whether one should be added, or whether this should be handled through the existing power management code somehow. I honestly don't know what the best answer is on this one - will have to do some digging. Suggestions welcome. Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
On Thu, 16 Jun 2011 11:12:03 +0800 Kassey Lee kassey1...@gmail.com wrote: 2) for mcam_ctlr_stop_dma implementation, I guess you know something about the silicon limitation, but we found it can not pass our stress test(1000 times capture test, which will switch format between JPEG and YUV again and again). our solution is : stop the ccic controller and wait for about one frame transfer time, and the stop the sensor. this passed our stress test. for your info. Actually, I know very little that's not in the datasheet. Are you telling me that there are hardware limitations that aren't documented, and that the datasheet is not a 100% accurate description of what's going on? I'm *shocked* I tell you! (For the record, with both Cafe and Armada 610, I've found the hardware to be more reasonable and in accord with the documentation than with many others.) In any case, I don't know about the limitation you're talking about here, could you elaborate a bit? For stress testing I've run video capture for weeks at a time, so obviously you're talking about something else. Sounds like something I need to know? 3) for videoubuf2, will you use videoubuf2 only or combined with soc-camera ? when can your driver for videoubuf2 ready ? Videobuf2 only. To be honest, I've never quite understood what soc-camera buys. If there's a reason to do a switch, it could be contemplated - but remember that Cafe is not an SoC device. The vb2 driver is working now in vmalloc mode, which is probably what Cafe will need forever. I do plan to add dma-contig, and, probably, dma-sg support in the very near future. If you want, I can post the vmalloc version later today; I just want to make one more pass over it first. 4) the point is: ccic and sensor driver should be independent, and support two CCIC controller. No disagreement there. I believe that two controllers should work now - though there's probably a gotcha somewhere since it's not actually been tried. Thanks, jon -- 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: Some fixes for alsa_stream
Em 16-06-2011 12:11, Hans de Goede escreveu: I've also changed the default -alsa-pb value to default as we should not be picking something else then the user / distro configured defaults for output IMHO. The user can set a generic default in alsarc, and override that on the cmdline if he/she wants, but unless overridden on the cmdline we should respect the users generic default as specified in his alsarc. While pulseaudio refuses to work via ssh, this is actually a very bad idea. Xawtv is used by developers to test their stuff, and they generally do it on a remote machine, with the console captured via tty port, in order to be able to catch panic messages. I'm sure developers are quite capable of creating either an .alsarc, pass the cmdline option, or change pulseaudio's config to accept non local console connections. As far as I noticed, most media developers seems to not be comfortable with pulseaudio. Using pulseaudio by default would require more experience from developers, otherwise nobody will be able to properly support it. For example, the only way I know that works to remove an audio module used by pulseaudio is by doing dirty tricks like: while : ; do kill pulseaudio; rmmod audio_module break; done I was told that there's a pactl syntax, but I was never able to find how to make it work, not even on a local console (and I need it supported via ssh). From other posts, other developers at this ML also didn't discover how to do it yet. A pulseaudio or .alsarc config to enable ssh would be fine, but, again, that's not obvious. While developers are not comfortable with pulseaudio, turning it into a default is a bad idea. We should try to have sane user oriented defaults, not developer oriented defaults. Also not all developers work the same way you do, so having a certain default just so it matches your work flow also is a bad idea IMHO. For now, please revert this patch. After having pulseaudio fixed to properly handle the audio group, I'm ok to re-add it. We could consider making the desired latency configurable, currently I've hardcoded it to 30 ms (was 38 with the old code on my system) note that I've chosen to specify the latency in ms rather then in a number of samples, since it should be samplerate independent IMO. Yeah, having latency configurable sounds a good idea to me. Done. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On 16 Jun 11 00:06, Arnd Bergmann wrote: On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote: On 15 Jun 11 10:36, Marek Szyprowski wrote: On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote: On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote: I've seen this split bank allocation in Qualcomm and TI SoCs, with Samsung, that makes 3 major SoC vendors (I would be surprised if Nvidia didn't also need to do this) - so I think some configurable method to control allocations is necessarily. The chips can't do decode without it (and by can't do I mean 1080P and higher decode is not functionally useful). Far from special, this would appear to be the default. We at Qualcomm have some platforms that have memory of different performance characteristics, some drivers will need a way of specifying that they need fast memory for an allocation (and would prefer an error if it is not available rather than a fallback to slower memory). It would also be bad if allocators who don't need fast memory got it accidentally, depriving those who really need it. Can you describe how the memory areas differ specifically? Is there one that is always faster but very small, or are there just specific circumstances under which some memory is faster than another? One is always faster, but very small (generally 2-10% the size of normal memory). Larry -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: uvcvideo failure under xHCI
On Thu, Jun 16, 2011 at 10:35:49AM -0400, Alan Stern wrote: On Thu, 16 Jun 2011, Laurent Pinchart wrote: On Thursday 16 June 2011 04:59:57 Sarah Sharp wrote: On Wed, Jun 15, 2011 at 06:39:57PM -0700, Sarah Sharp wrote: I've grepped through drivers/media/video, and it seems like none of the drivers handle the -EXDEV status. What should the xHCI driver be setting the URB's status and frame status to when the xHCI host controller skips over transfers? -EREMOTEIO? Or does it need to set the URB's status to zero, but only set the individual frame status to -EXDEV? Ok, looking at both EHCI and UHCI, they seem to set the urb-status to zero, regardless of what they set the frame descriptor field to. Alan, does that seem correct? The description of the behavior of ehci-hcd and uhci-hcd is correct. ohci-hcd behaves the same way too. And they all agree with the behavior described in the kerneldoc for struct urb in include/linux/usb.h. Ah, you mean this bit? * @status: This is read in non-iso completion functions to get the * status of the particular request. ISO requests only use it * to tell whether the URB was unlinked; detailed status for * each frame is in the fields of the iso_frame-desc. According to Documentation/usb/error-codes.txt, host controller drivers should set the status to -EXDEV. However, no device drivers seem to handle that, probably because the EHCI/UHCI drivers don't use that error code. Drivers are clearly out of sync with the documentation, so we should fix one of them. Under the circumstances, the documentation file should be changed. Sarah, can you do that along with the change to xhci-hcd? Sure. It feels like there should be a note about which values isochronous URBs might have in the urb-status field. The USB core is the only one that would be setting those, so which values would it set? uvcvideo tests for these error codes: case -ENOENT: /* usb_kill_urb() called. */ case -ECONNRESET: /* usb_unlink_urb() called. */ case -ESHUTDOWN:/* The endpoint is being disabled. */ case -EPROTO: /* Device is disconnected (reported by some * host controller). */ Are there any others. Sarah Sharp -- 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] dvb: remove unnecessary code
remove unnecessary code that matches this coccinelle pattern if (...) return ret; return ret; Signed-off-by: Greg Dietsche gregory.diets...@cuw.edu --- drivers/media/dvb/frontends/cx24116.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/media/dvb/frontends/cx24116.c b/drivers/media/dvb/frontends/cx24116.c index 95c6465..ccd0525 100644 --- a/drivers/media/dvb/frontends/cx24116.c +++ b/drivers/media/dvb/frontends/cx24116.c @@ -1452,11 +1452,7 @@ tuned: /* Set/Reset B/W */ cmd.args[0x00] = CMD_BANDWIDTH; cmd.args[0x01] = 0x00; cmd.len = 0x02; - ret = cx24116_cmd_execute(fe, cmd); - if (ret != 0) - return ret; - - return ret; + return cx24116_cmd_execute(fe, cmd); } static int cx24116_tune(struct dvb_frontend *fe, struct dvb_frontend_parameters *params, -- 1.7.2.5 -- 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: uvcvideo failure under xHCI
On Thu, 16 Jun 2011, Sarah Sharp wrote: Alan, does that seem correct? The description of the behavior of ehci-hcd and uhci-hcd is correct. ohci-hcd behaves the same way too. And they all agree with the behavior described in the kerneldoc for struct urb in include/linux/usb.h. Ah, you mean this bit? * @status: This is read in non-iso completion functions to get the * status of the particular request. ISO requests only use it * to tell whether the URB was unlinked; detailed status for * each frame is in the fields of the iso_frame-desc. Right. There's also some more near the end: * Completion Callbacks: * * The completion callback is made in_interrupt(), and one of the first * things that a completion handler should do is check the status field. * The status field is provided for all URBs. It is used to report * unlinked URBs, and status for all non-ISO transfers. It should not * be examined before the URB is returned to the completion handler. Under the circumstances, the documentation file should be changed. Sarah, can you do that along with the change to xhci-hcd? Sure. It feels like there should be a note about which values isochronous URBs might have in the urb-status field. The USB core is the only one that would be setting those, so which values would it set? uvcvideo tests for these error codes: case -ENOENT: /* usb_kill_urb() called. */ case -ECONNRESET: /* usb_unlink_urb() called. */ case -ESHUTDOWN:/* The endpoint is being disabled. */ case -EPROTO: /* Device is disconnected (reported by some * host controller). */ Are there any others. -EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no others. And I wasn't aware of that last one... Host controller drivers should report -ESHUTDOWN to mean the device has been disconnected, not -EPROTO. But usually HCD don't take these events into account when determining URB status codes. Alan Stern -- 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: Some fixes for alsa_stream
Hi, On 06/16/2011 05:35 PM, Mauro Carvalho Chehab wrote: Em 16-06-2011 12:11, Hans de Goede escreveu: snip While developers are not comfortable with pulseaudio, turning it into a default is a bad idea. 1) Some developers are fine with pulseaudio, so please speak on behalf of yourself rather then of developers. Disclaimer I've written patches to the alsa code for many a program to work properly with pulseaudio's alsa glue layer as well as (re)written the SDL pulseaudio backend. 2) Developers who are not comfortable with pulseaudio now, should better learn pulseaudio since that is what the majority of our users are using 3) I'm not making pulseaudio default *at all*. I'm making the default alsa device the default. Which seems like a very sane default to me. Does your default alsa device happen to point to pulseaudio, and you don't want that, plenty of options: 1) pass -alsa-pb hw to xawtv (requires no pulseaudio knowledge) 2) Set a different default alsa device in .alsarc (requires no pulseaudio knowledge, trivial alsa knowledge) 3) Do rpm -e alsa-plugins-pulseaudio Noe that 3 will permanently make any alsa using app use alsa directly instead of PA, which seems to be just what you want. Regards, Hans -- 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
New channels list sk-Presov
Hello. I would like to commit channel list sk-Presov as suggested in README of utility scan from dvb-apps. Please let me know if anything is missing in this list. Thank You -- S podzravom / Kind regards, Viktor Kristian # DVB-T Prešov (Prešov, Slovak Republic) # Created from http://www.dvbt.towercom.sk/odbornici.php # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy # MUX1 - Pilot - on channel 64 T 81800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # MUX2 - Commercial - on channel 59 T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE # MUX3 - Public - on channel 25 T 50600 8MHz 2/3 NONE QAM64 8k 1/4 NONE smime.p7s Description: S/MIME cryptographic signature
Re: Some fixes for alsa_stream
Em 16-06-2011 15:19, Hans de Goede escreveu: Hi, 1) pass -alsa-pb hw to xawtv (requires no pulseaudio knowledge) 2) Set a different default alsa device in .alsarc (requires no pulseaudio knowledge, trivial alsa knowledge) 3) Do rpm -e alsa-plugins-pulseaudio Noe that 3 will permanently make any alsa using app use alsa directly instead of PA, which seems to be just what you want. Even 3 still doesn't solve rmmod alsa-module On desktops, an yum remove -y pulseaudio work, but bluetooth depends on it, so this also doesn't provide a solution for notebooks. Anyway, for now I'll do it on all my instances with pulseaudio, while nobody provides a solution for rmmod. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Jun 16 19:00:34 CEST 2011 git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: uvcvideo failure under xHCI
On Thu, Jun 16, 2011 at 01:39:43PM -0400, Alan Stern wrote: On Thu, 16 Jun 2011, Sarah Sharp wrote: Alan, does that seem correct? The description of the behavior of ehci-hcd and uhci-hcd is correct. ohci-hcd behaves the same way too. And they all agree with the behavior described in the kerneldoc for struct urb in include/linux/usb.h. Ah, you mean this bit? * @status: This is read in non-iso completion functions to get the * status of the particular request. ISO requests only use it * to tell whether the URB was unlinked; detailed status for * each frame is in the fields of the iso_frame-desc. Right. There's also some more near the end: * Completion Callbacks: * * The completion callback is made in_interrupt(), and one of the first * things that a completion handler should do is check the status field. * The status field is provided for all URBs. It is used to report * unlinked URBs, and status for all non-ISO transfers. It should not * be examined before the URB is returned to the completion handler. Under the circumstances, the documentation file should be changed. Sarah, can you do that along with the change to xhci-hcd? Sure. It feels like there should be a note about which values isochronous URBs might have in the urb-status field. The USB core is the only one that would be setting those, so which values would it set? uvcvideo tests for these error codes: case -ENOENT: /* usb_kill_urb() called. */ case -ECONNRESET: /* usb_unlink_urb() called. */ case -ESHUTDOWN:/* The endpoint is being disabled. */ case -EPROTO: /* Device is disconnected (reported by some * host controller). */ Are there any others. -EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no others. Are you saying that the USB core will only set -EREMOTEIO for isochronous URBs? Or do you mean that in addition to the status values that uvcvideo checks, the USB core can also set -EREMOTEIO? And I wasn't aware of that last one... Host controller drivers should report -ESHUTDOWN to mean the device has been disconnected, not -EPROTO. But usually HCD don't take these events into account when determining URB status codes. The xHCI driver will return -ESHUTDOWN as a status for URBs when the host controller is dying. Sarah Sharp -- 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] OMAP_VOUT: Change hardcoded device node number to -1
From: Vaibhav Hiremath hvaib...@ti.com With addition of media-controller framework, now we have various device nodes (/dev/videoX) getting created, so hardcoding minor number in video_register_device() is not recommended. So let V4L2 framework choose free minor number for the device. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/omap/omap_vout.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 0bc776c..3bc909a 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -1993,7 +1993,7 @@ static int __init omap_vout_create_video_devices(struct platform_device *pdev) /* Register the Video device with V4L2 */ vfd = vout-vfd; - if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) 0) { + if (video_register_device(vfd, VFL_TYPE_GRABBER, -1) 0) { dev_err(pdev-dev, : Could not register Video for Linux device\n); vfd-minor = -1; -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DVB: dvb-net, make the kconfig text helpful
Telling the user they can disable an option if they want is not the much useful. Describe what it is good for instead. The text was derived from Mauro's email. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Hans Petter Selasky hsela...@c2i.net --- drivers/media/Kconfig | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index dc61895..279e2b9 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -89,11 +89,13 @@ config DVB_NET default (NET INET) depends on NET INET help - The DVB network support in the DVB core can - optionally be disabled if this - option is set to N. + This option enables DVB Network Support which is a part of the DVB + standard. It is used, for example, by automatic firmware updates used + on Set-Top-Boxes. It can also be used to access the Internet via the + DVB card, if the network provider supports it. - If unsure say Y. + You may want to disable the network support on embedded devices. If + unsure say Y. config VIDEO_MEDIA tristate -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] rc: fix ghost keypresses with certain hw
With hardware that has to use ir_raw_event_store_edge to collect IR sample durations, we were not doing an event reset unless IR_MAX_DURATION had passed. That's around 4 seconds. So if someone presses up, then down, with less than 4 seconds in between, they'd get the initial up, then up and down upon pressing down. To fix this, I've lowered the send a reset event logic's threshold to the input device's REP_DELAY (defaults to 500ms), and with an saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get *much* better behavior out of the remote now. Special thanks to Devin for providing the hardware to investigate this issue. CC: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/rc/ir-raw.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/rc/ir-raw.c b/drivers/media/rc/ir-raw.c index f4efd2f..27808bb 100644 --- a/drivers/media/rc/ir-raw.c +++ b/drivers/media/rc/ir-raw.c @@ -114,18 +114,20 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum raw_event_type type) s64 delta; /* ns */ DEFINE_IR_RAW_EVENT(ev); int rc = 0; + int delay; if (!dev-raw) return -EINVAL; now = ktime_get(); delta = ktime_to_ns(ktime_sub(now, dev-raw-last_event)); + delay = MS_TO_NS(dev-input_dev-rep[REP_DELAY]); /* Check for a long duration since last event or if we're * being called for the first time, note that delta can't * possibly be negative. */ - if (delta IR_MAX_DURATION || !dev-raw-last_type) + if (delta delay || !dev-raw-last_type) type |= IR_START_EVENT; else ev.duration = delta; -- 1.7.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
[PATCH] [staging] lirc_serial: allocate irq at init time
There's really no good reason not to just grab the desired IRQ at driver init time, instead of every time the lirc device node is accessed. This also improves the speed and reliability with which a serial transmitter can operate, as back-to-back transmission attempts (i.e., channel change to a multi-digit channel) don't have to spend time acquiring and then releasing the IRQ for every digit, sometimes multiple times, if lircd has been told to use the min_repeat parameter. CC: de...@driverdev.osuosl.org Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/staging/lirc/lirc_serial.c | 44 +-- 1 files changed, 21 insertions(+), 23 deletions(-) diff --git a/drivers/staging/lirc/lirc_serial.c b/drivers/staging/lirc/lirc_serial.c index 1c3099b..805df91 100644 --- a/drivers/staging/lirc/lirc_serial.c +++ b/drivers/staging/lirc/lirc_serial.c @@ -838,7 +838,23 @@ static int hardware_init_port(void) static int init_port(void) { - int i, nlow, nhigh; + int i, nlow, nhigh, result; + + result = request_irq(irq, irq_handler, +IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0), +LIRC_DRIVER_NAME, (void *)hardware); + + switch (result) { + case -EBUSY: + printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq); + return -EBUSY; + case -EINVAL: + printk(KERN_ERR LIRC_DRIVER_NAME + : Bad irq number or handler\n); + return -EINVAL; + default: + break; + }; /* Reserve io region. */ /* @@ -893,34 +909,17 @@ static int init_port(void) printk(KERN_INFO LIRC_DRIVER_NAME : Manually using active %s receiver\n, sense ? low : high); + dprintk(Interrupt %d, port %04x obtained\n, irq, io); return 0; } static int set_use_inc(void *data) { - int result; unsigned long flags; /* initialize timestamp */ do_gettimeofday(lasttv); - result = request_irq(irq, irq_handler, -IRQF_DISABLED | (share_irq ? IRQF_SHARED : 0), -LIRC_DRIVER_NAME, (void *)hardware); - - switch (result) { - case -EBUSY: - printk(KERN_ERR LIRC_DRIVER_NAME : IRQ %d busy\n, irq); - return -EBUSY; - case -EINVAL: - printk(KERN_ERR LIRC_DRIVER_NAME - : Bad irq number or handler\n); - return -EINVAL; - default: - dprintk(Interrupt %d, port %04x obtained\n, irq, io); - break; - }; - spin_lock_irqsave(hardware[type].lock, flags); /* Set DLAB 0. */ @@ -945,10 +944,6 @@ static void set_use_dec(void *data) soutp(UART_IER, sinp(UART_IER) (~(UART_IER_MSI|UART_IER_RLSI|UART_IER_THRI|UART_IER_RDI))); spin_unlock_irqrestore(hardware[type].lock, flags); - - free_irq(irq, (void *)hardware); - - dprintk(freed IRQ %d\n, irq); } static ssize_t lirc_write(struct file *file, const char *buf, @@ -1256,6 +1251,9 @@ exit_serial_exit: static void __exit lirc_serial_exit_module(void) { lirc_serial_exit(); + + free_irq(irq, (void *)hardware); + if (iommap != 0) release_mem_region(iommap, 8 ioshift); else -- 1.7.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
Re: uvcvideo failure under xHCI
On Thu, 16 Jun 2011, Sarah Sharp wrote: Sure. It feels like there should be a note about which values isochronous URBs might have in the urb-status field. The USB core is the only one that would be setting those, so which values would it set? uvcvideo tests for these error codes: case -ENOENT: /* usb_kill_urb() called. */ case -ECONNRESET: /* usb_unlink_urb() called. */ case -ESHUTDOWN:/* The endpoint is being disabled. */ case -EPROTO: /* Device is disconnected (reported by some * host controller). */ Are there any others. -EREMOTEIO, in the unlikely event that URB_SHORT_NOT_OK is set, but no others. Are you saying that the USB core will only set -EREMOTEIO for isochronous URBs? Or do you mean that in addition to the status values that uvcvideo checks, the USB core can also set -EREMOTEIO? The latter. However, if uvcvideo never sets the URB_SHORT_NOT_OK flag then usbcore will never set urb-status to -EREMOTEIO. And I wasn't aware of that last one... Host controller drivers should report -ESHUTDOWN to mean the device has been disconnected, not -EPROTO. But usually HCD don't take these events into account when determining URB status codes. The xHCI driver will return -ESHUTDOWN as a status for URBs when the host controller is dying. That's appropriate. But nobody should ever set an isochronous URB's status field to -EPROTO, no matter whether the device is connected or not and no matter whether the host controller is alive or not. Alan Stern -- 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 8/8] marvell-cam: Basic working MMP camera driver
Hello, On 06/16/2011 05:17 PM, Jonathan Corbet wrote: On Thu, 16 Jun 2011 10:37:37 +0800 Kassey Leekassey1...@gmail.com wrote: +static void mmpcam_power_down(struct mcam_camera *mcam) +{ + struct mmp_camera *cam = mcam_to_cam(mcam); + struct mmp_camera_platform_data *pdata; +/* + * Turn off clocks and set reset lines + */ + iowrite32(0, cam-power_regs + REG_CCIC_DCGCR); + iowrite32(0, cam-power_regs + REG_CCIC_CRCR); +/* + * Shut down the sensor. + */ + pdata = cam-pdev-dev.platform_data; + gpio_set_value(pdata-sensor_power_gpio, 0); + gpio_set_value(pdata-sensor_reset_gpio, 0); it is better to have a callback function to controller sensor power on/off. and place the callback function in board.c It might be more convenient for the driver writer but I do not think it is generally better. Platform callbacks cannot really be migrated to FDT. For reasons pointed out by Jon below I have also been trying to avoid callbacks in sensors' platform data. This is an interesting question, actually. The problem is that board files are on their way out; it's going to be very hard to get any more board files into the mainline going forward. The mmp-camera driver does depend on a board file, but I've been careful to restrict things to basic platform data which can just as easily be put into a device tree. Power management callbacks don't really qualify. So it seems that we need to figure out a way to push this kind of pin/power management down into the sensor-specific code. Looking at the subdev stuff, it looks like a bit of thought has been put into that direction; there's the s_io_pin_config() callback to describe pins to the But having sensor's GPIOs configured by bridge driver does not help us much here, does it? The bridge driver would still need to retrieve the sensor configuration from somewhere, since it is machine/board specific. And it's the subdev driver that will know how the GPIOs should be handled, the timing constraints, etc. So as long as we can pass gpio numbers from a device tree to subdevs we probably do not need an additional subdev operation. I guess when there come more subdev drivers dealing with GPIOs we could try and see what could be generalized. sensor. But it's almost entirely unused. There is no power up/down callback, currently. We could ponder on We have the subdev s_power core operation in struct v4l2_subdev_core_ops. However it seems that its semantic is not yet clearly documented. whether one should be added, or whether this should be handled through the existing power management code somehow. I honestly don't know what the best answer is on this one - will have to do some digging. Suggestions welcome. -- Regards, Sylwester -- 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: uvcvideo failure under xHCI
On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote: That's appropriate. But nobody should ever set an isochronous URB's status field to -EPROTO, no matter whether the device is connected or not and no matter whether the host controller is alive or not. But the individual frame status be set to -EPROTO, correct? That's what Alex was told to do when an isochronous TD had a completion code of Incompatible Device Error. Sarah Sharp -- 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] omap_vout: Added check in reqbuf mmap for buf_size allocation
From: Vaibhav Hiremath hvaib...@ti.com The usecase where, user allocates small size of buffer through bootargs (video1_bufsize/video2_bufsize) and later from application tries to set the format which requires larger buffer size, driver doesn't check for insufficient buffer size and allows application to map extra buffer. This leads to kernel crash, when user application tries to access memory beyond the allocation size. Added check in both mmap and reqbuf call back function, and return error if the size of the buffer allocated by user through bootargs is less than the S_FMT size. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/omap/omap_vout.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 3bc909a..343b50c 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -678,6 +678,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, startindex = (vout-vid == OMAP_VIDEO1) ? video1_numbuffers : video2_numbuffers; + /* Check the size of the buffer */ + if (*size vout-buffer_size) { + v4l2_err(vout-vid_dev-v4l2_dev, + buffer allocation mismatch [%u] [%u]\n, + *size, vout-buffer_size); + return -ENOMEM; + } + for (i = startindex; i *count; i++) { vout-buffer_size = *size; @@ -856,6 +864,14 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) (vma-vm_pgoff PAGE_SHIFT)); return -EINVAL; } + /* Check the size of the buffer */ + if (size vout-buffer_size) { + v4l2_err(vout-vid_dev-v4l2_dev, + insufficient memory [%lu] [%u]\n, + size, vout-buffer_size); + return -ENOMEM; + } + q-bufs[i]-baddr = vma-vm_start; vma-vm_flags |= VM_RESERVED; -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo failure under xHCI
On Thu, 16 Jun 2011, Sarah Sharp wrote: On Thu, Jun 16, 2011 at 03:39:11PM -0400, Alan Stern wrote: That's appropriate. But nobody should ever set an isochronous URB's status field to -EPROTO, no matter whether the device is connected or not and no matter whether the host controller is alive or not. But the individual frame status be set to -EPROTO, correct? That's what Alex was told to do when an isochronous TD had a completion code of Incompatible Device Error. Right. -EPROTO is a perfectly reasonable code for a frame's status. But not for an isochronous URB's status. There's no reason for uvcvideo to test for it. Alan Stern -- 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] [media] saa7134: fix raw IR timeout value
The comment says wait 15ms, but the code says jiffies_to_msecs(15) instead of msecs_to_jiffies(15). Fix that. Tested, works fine with both rc5 and rc6 decode, in-kernel and via lirc userspace, with an HVR-1150. Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/video/saa7134/saa7134-input.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index ff6c0e9..d4ee24b 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -963,7 +963,7 @@ static int saa7134_raw_decode_irq(struct saa7134_dev *dev) * to work with other protocols. */ if (!ir-active) { - timeout = jiffies + jiffies_to_msecs(15); + timeout = jiffies + msecs_to_jiffies(15); mod_timer(ir-timer, timeout); ir-active = true; } -- 1.7.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
RTL2831U driver updates
Sascha: Thanks for the links Would you know how to contact poma ? http://www.spinics.net/lists/linux-media/msg24890.html I will be getting more info from Realtek soon. I did not realize that they were putting out updated drivers. Once the status becomes more clear, I'll update http://www.linuxtv.org/wiki/index.php/Realtek_RTL2831U Sascha Wüstemann wrote: Thomas Holzeisen wrote: Hi there, I tried to get an RTL2831U dvb-t usb-stick running with a more recent kernel (2.6.38) and failed. The hg respository ~jhoogenraad/rtl2831-r2 aborts on countless drivers, the rc coding seem have to changed a lot since it got touched the last time. The hg respository ~anttip/rtl2831u wont compile as well, since its even older. The recent git respositories for media_tree and anttip dont contain drivers for the rtl2831u. Has this device been abandoned, or is anyone working on it? greetings, Thomas There are still people working on it and there is new sources, e.g. look at http://www.spinics.net/lists/linux-media/msg24890.html at the very bottom. Worked like a charm at my system with kernel 2.6.39. I think, there will be announcements later at http://wiki.zeratul.org/doku.php?id=linux:v4l:realtek:start Greetings from Braunschweig, Germany. Sascha -- 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 -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
Em 15-06-2011 23:30, Kassey Lee escreveu: 2011/6/14 Jonathan Corbet cor...@lwn.net: On Tue, 14 Jun 2011 10:58:47 +0800 Kassey Lee kassey1...@gmail.com wrote: + /* +* Try to find the sensor. +*/ + cam-sensor_addr = ov7670_info.addr; + cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev, + cam-i2c_adapter, ov7670_info, NULL); I do not thinks so. I don't understand what this comment is meant to mean...? this should be move out to arch/arm/mach-xxx/board.c Please drop the parts that you're not commenting. It is very hard to find a one-line comment in the middle of a long patch, especially since you don't even add blank lines before/after it. With respect to your comment, it doesn't makes much sense,as cafe_ccic runs on OLPC 1 hardware (at least the version I have here) is x86-based. So, I'm not seeing any reason why not apply patch 2/8. Applying on my tree. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
Em 16-06-2011 12:27, Jonathan Corbet escreveu: On Thu, 16 Jun 2011 11:12:03 +0800 Kassey Lee kassey1...@gmail.com wrote: 2) for mcam_ctlr_stop_dma implementation, I guess you know something about the silicon limitation, but we found it can not pass our stress test(1000 times capture test, which will switch format between JPEG and YUV again and again). our solution is : stop the ccic controller and wait for about one frame transfer time, and the stop the sensor. this passed our stress test. for your info. Actually, I know very little that's not in the datasheet. Are you telling me that there are hardware limitations that aren't documented, and that the datasheet is not a 100% accurate description of what's going on? I'm *shocked* I tell you! (For the record, with both Cafe and Armada 610, I've found the hardware to be more reasonable and in accord with the documentation than with many others.) In any case, I don't know about the limitation you're talking about here, could you elaborate a bit? For stress testing I've run video capture for weeks at a time, so obviously you're talking about something else. Sounds like something I need to know? 3) for videoubuf2, will you use videoubuf2 only or combined with soc-camera ? when can your driver for videoubuf2 ready ? Videobuf2 only. To be honest, I've never quite understood what soc-camera buys. If there's a reason to do a switch, it could be contemplated - but remember that Cafe is not an SoC device. The vb2 driver is working now in vmalloc mode, which is probably what Cafe will need forever. I do plan to add dma-contig, and, probably, dma-sg support in the very near future. If you want, I can post the vmalloc version later today; I just want to make one more pass over it first. 4) the point is: ccic and sensor driver should be independent, and support two CCIC controller. No disagreement there. I believe that two controllers should work now - though there's probably a gotcha somewhere since it's not actually been tried. Well, I'll be applying the patch series, as the above seems to be points for future improvements, and don't seem to prevent the addition of this patch series. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] marvell-cam: Right-shift i2c slave ID's in the cafe driver
Em 11-06-2011 14:46, Jonathan Corbet escreveu: This makes the cafe i2c implement consistent with the rest of Linux so that the core can use the same slave ID everywhere. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/cafe-driver.c |9 - drivers/media/video/marvell-ccic/mcam-core.c |2 +- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c b/drivers/media/video/marvell-ccic/cafe-driver.c index 1027265..3dbc7e5 100644 --- a/drivers/media/video/marvell-ccic/cafe-driver.c +++ b/drivers/media/video/marvell-ccic/cafe-driver.c @@ -84,7 +84,14 @@ struct cafe_camera { #defineTWSIC0_EN 0x0001/* TWSI enable */ #defineTWSIC0_MODE 0x0002/* 1 = 16-bit, 0 = 8-bit */ #defineTWSIC0_SID 0x03fc/* Slave ID */ -#defineTWSIC0_SID_SHIFT 2 +/* + * Subtle trickery: the slave ID field starts with bit 2. But the + * Linux i2c stack wants to treat the bottommost bit as a separate + * read/write bit, which is why slave ID's are usually presented + * 1. For consistency with that behavior, we shift over three + * bits instead of two. + */ And this is consistent with the initial Philips I2C datasheets ;) Newer datasheets use to include the read/write bit as if they're part of the I2C address, as well as the registers that command I2C operations inside most chipsets. So, we end by having 7-bit and 8-bit notations for I2C addresses. +#defineTWSIC0_SID_SHIFT 3 #defineTWSIC0_CLKDIV 0x0007fc00/* Clock divider */ #defineTWSIC0_MASKACK 0x0040/* Mask ack from sensor */ #defineTWSIC0_OVMAGIC 0x0080/* Make it work on OV sensors */ diff --git a/drivers/media/video/marvell-ccic/mcam-core.c b/drivers/media/video/marvell-ccic/mcam-core.c index 0d60234..d5f18a3 100644 --- a/drivers/media/video/marvell-ccic/mcam-core.c +++ b/drivers/media/video/marvell-ccic/mcam-core.c @@ -1549,7 +1549,7 @@ int mccic_register(struct mcam_camera *cam) { struct i2c_board_info ov7670_info = { .type = ov7670, - .addr = 0x42, + .addr = 0x42 1, .platform_data = sensor_cfg, }; int ret; Patch is OK. Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] marvell-cam: Basic working MMP camera driver
Em 16-06-2011 16:44, Sylwester Nawrocki escreveu: Hello, On 06/16/2011 05:17 PM, Jonathan Corbet wrote: On Thu, 16 Jun 2011 10:37:37 +0800 Kassey Leekassey1...@gmail.com wrote: +static void mmpcam_power_down(struct mcam_camera *mcam) +{ + struct mmp_camera *cam = mcam_to_cam(mcam); + struct mmp_camera_platform_data *pdata; +/* + * Turn off clocks and set reset lines + */ + iowrite32(0, cam-power_regs + REG_CCIC_DCGCR); + iowrite32(0, cam-power_regs + REG_CCIC_CRCR); +/* + * Shut down the sensor. + */ + pdata = cam-pdev-dev.platform_data; + gpio_set_value(pdata-sensor_power_gpio, 0); + gpio_set_value(pdata-sensor_reset_gpio, 0); it is better to have a callback function to controller sensor power on/off. and place the callback function in board.c It might be more convenient for the driver writer but I do not think it is generally better. Platform callbacks cannot really be migrated to FDT. For reasons pointed out by Jon below I have also been trying to avoid callbacks in sensors' platform data. Well, outside the SoC world, we use two different approaches for GPIO: The first and more used one is to add the GPIO settings into a per-card model table (see the tables at cx88-cards, em28xx-cards, etc). Once the driver detects what's the card model (by USB ID or PCI ID), it selects one line at the board table entry. This works better than callbacks, and are very simple to code. Unfortunately, on a few cases, the GPIO's need to be set during a subdev operation, on several tuners, like the Xceive family of tuners, that require a chip reset via GPIO during firmware load. This is an interesting question, actually. The problem is that board files are on their way out; it's going to be very hard to get any more board files into the mainline going forward. The mmp-camera driver does depend on a board file, but I've been careful to restrict things to basic platform data which can just as easily be put into a device tree. Power management callbacks don't really qualify. So it seems that we need to figure out a way to push this kind of pin/power management down into the sensor-specific code. Looking at the subdev stuff, it looks like a bit of thought has been put into that direction; there's the s_io_pin_config() callback to describe pins to the But having sensor's GPIOs configured by bridge driver does not help us much here, does it? The bridge driver would still need to retrieve the sensor configuration from somewhere, since it is machine/board specific. And it's the subdev driver that will know how the GPIOs should be handled, the timing constraints, etc. So as long as we can pass gpio numbers from a device tree to subdevs we probably do not need an additional subdev operation. I guess when there come more subdev drivers dealing with GPIOs we could try and see what could be generalized. On my experiences, the timings and even the meanings for GPIO's are not subdev specific, at least outside SoC world. Especially when you have multiple devices sharing the same I2C bus, timings need to be adjusted to avoid troubles with other chips, and due to capacitance effects at the board tracks. sensor. But it's almost entirely unused. There is no power up/down callback, currently. We could ponder on We have the subdev s_power core operation in struct v4l2_subdev_core_ops. However it seems that its semantic is not yet clearly documented. Yes, s_power is meant to be used for putting a sub-device to sleep or for waking it up. whether one should be added, or whether this should be handled through the existing power management code somehow. I honestly don't know what the best answer is on this one - will have to do some digging. Suggestions welcome. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/17 Mauro Carvalho Chehab mche...@infradead.org: Em 15-06-2011 23:30, Kassey Lee escreveu: 2011/6/14 Jonathan Corbet cor...@lwn.net: On Tue, 14 Jun 2011 10:58:47 +0800 Kassey Lee kassey1...@gmail.com wrote: + /* + * Try to find the sensor. + */ + cam-sensor_addr = ov7670_info.addr; + cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev, + cam-i2c_adapter, ov7670_info, NULL); I do not thinks so. I don't understand what this comment is meant to mean...? this should be move out to arch/arm/mach-xxx/board.c Please drop the parts that you're not commenting. It is very hard to find a one-line comment in the middle of a long patch, especially since you don't even add blank lines before/after it. sorry for the confusion. this is the same idea that we want to separate the ccic driver and sensor info. here is how we do this: on arch/arm/mach-mmp/ttc_dkb.c static struct i2c_board_info dkb_i2c_camera[] = { { I2C_BOARD_INFO(ov5642, 0x3c), }, }; i2c_register_board_info(0, dkb_i2c_camera, 1); With respect to your comment, it doesn't makes much sense,as cafe_ccic runs on OLPC 1 hardware (at least the version I have here) is x86-based. that is fine, sorry, i always thought it was ARM platform. So, I'm not seeing any reason why not apply patch 2/8. Applying on my tree. Mauro. -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
2011/6/16 Jonathan Corbet cor...@lwn.net: On Thu, 16 Jun 2011 11:12:03 +0800 Kassey Lee kassey1...@gmail.com wrote: 2) for mcam_ctlr_stop_dma implementation, I guess you know something about the silicon limitation, but we found it can not pass our stress test(1000 times capture test, which will switch format between JPEG and YUV again and again). our solution is : stop the ccic controller and wait for about one frame transfer time, and the stop the sensor. this passed our stress test. for your info. Actually, I know very little that's not in the datasheet. Are you telling me that there are hardware limitations that aren't documented, and that the datasheet is not a 100% accurate description of what's going on? I'm *shocked* I tell you! (For the record, with both Cafe and Armada 610, I've found the hardware to be more reasonable and in accord with the documentation than with many others.) In any case, I don't know about the limitation you're talking about here, could you elaborate a bit? For stress testing I've run video capture for weeks at a time, so obviously you're talking about something else. Sounds like something I need to know? hi, Jon: the problem is: when we stop CCIC, and then switch to another format. at this stage, actually, CCIC DMA is not stopped until the transferring frame is done. this will cause system hang if we start CCIC again with another format. we've ask silicon design to add CCIC DMA stop/start controller bit. from your logic, when stop DMA, you are test the EOF/SOF, so I wonder why you want to do this ? and is your test will stop CCIC and start CCIC frequently ? thanks 3) for videoubuf2, will you use videoubuf2 only or combined with soc-camera ? when can your driver for videoubuf2 ready ? Videobuf2 only. To be honest, I've never quite understood what soc-camera buys. If there's a reason to do a switch, it could be contemplated - but remember that Cafe is not an SoC device. The vb2 driver is working now in vmalloc mode, which is probably what Cafe will need forever. I do plan to add dma-contig, and, probably, dma-sg support in the very near future. If you want, I can post the vmalloc version later today; I just want to make one more pass over it first. could you please share the vmalloc way to me ? and if the dma-contig is OK, I'm glad to verify on our platform. as to test USERPTR, we are using a PMEM to get phy-contig memory in user space, and then QBUF to driver. 4) the point is: ccic and sensor driver should be independent, and support two CCIC controller. No disagreement there. I believe that two controllers should work now - though there's probably a gotcha somewhere since it's not actually been tried. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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