[GIT PATCHES FOR 3.2] auto-cluster bug fix
Hi Mauro, Here is a small fix for a bug in the autocluster handling that was found by Hans de Goede. Regards, Hans The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd: [media] it913x-fe changes to power up and down of tuner (2011-10-08 08:03:27 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ctrlfix Hans Verkuil (1): v4l2-ctrls: if auto-cluster flags change, then send event to all. drivers/media/video/v4l2-ctrls.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] omap3isp: add BT656 support
On Wed, Oct 12, 2011 at 12:34 AM, Gary Thomas g...@mlbassoc.com wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.com wrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout In multimedia/video capture/omap2 video4linux I had it disabled and enabling it gave me an error too, but it's not something that is changed by my patches so it is broken in the -yuv tree. I made a distclean rebuild and i don't have any errors, are you sure you need that include in ispccdc.c? Enrico -- 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] Staging: cx25821: off by on in cx25821_vidioc_s_input()
On Tue, Oct 11, 2011 at 05:59:25PM -0300, Mauro Carvalho Chehab wrote:
- if (i 2) {
+ if (i = 2) {
It would be better to add a NUM_INPUT macro (or something like that, defined
together
with the INPUT macro) that would do an ARRAY_SIZE(cx25821_boards) and use it
here,
instead of a 2 magic number.
You're right. The hard coded 2 is not helpful... Why not just an:
if (i = ARRAY_SIZE(cx25821_boards)) {...
I'll send a patch to do that.
regards,
dan carpenter
--
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] Staging: cx25821: off by on in cx25821_vidioc_s_input()
Never mind. I figured out what you meant. I've fixed my patch and I will send v2 this evening. regards, dan carpenter -- 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: [GIT PATCHES FOR 3.2] auto-cluster bug fix
On Wednesday, October 12, 2011 10:00:57 Hans Verkuil wrote: Hi Mauro, Here is a small fix for a bug in the autocluster handling that was found by Hans de Goede. I've added one more fix: V4L spec: fix typo and missing CAP_RDS documentation. Regards, Hans Regards, Hans The following changes since commit e30528854797f057aa6ffb6dc9f890e923c467fd: [media] it913x-fe changes to power up and down of tuner (2011-10-08 08:03:27 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ctrlfix Hans Verkuil (1): v4l2-ctrls: if auto-cluster flags change, then send event to all. drivers/media/video/v4l2-ctrls.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 1/4] v4l: add support for selection api
Hi Tomasz,
On Wed, Aug 31, 2011 at 02:28:20PM +0200, Tomasz Stanislawski wrote:
...
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..b7471fe 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,48 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
A minor comment. If the patches have not been pulled yet, how about adding
FLAG_ to the flag names? I.e. V4L2_SEL_FLAG_SIZE_GE and
V4L2_SEL_FLAG_SIZE_LE.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] omap3isp: add BT656 support
On 2011-10-12 02:07, Enrico wrote: On Wed, Oct 12, 2011 at 12:34 AM, Gary Thomasg...@mlbassoc.com wrote: On 2011-10-11 16:25, Enrico wrote: On Wed, Oct 12, 2011 at 12:04 AM, Gary Thomasg...@mlbassoc.comwrote: Sorry, this just locks up on boot for me, immediately after finding the TVP5150. I applied your changes to the above tree commit 658d5e03dc1a7283e5119cd0e9504759dbd3d912 Author: Laurent Pinchartlaurent.pinch...@ideasonboard.com Date: Wed Aug 31 16:03:53 2011 +0200 Did you add Javier patches for the tvp5150? No, I thought your set was self-contained. I'll add them now. However, it does not build for my OMAP3530 without the attached patches. I can't remember now if i had omap vout enabled in my kernel config but that one in ispccdc.c is strange, tomorrow i will do again a clean rebuild. I can't see how to turn off omap_vout In multimedia/video capture/omap2 video4linux I had it disabled and enabling it gave me an error too, but it's not something that is changed by my patches so it is broken in the -yuv tree. I made a distclean rebuild and i don't have any errors, are you sure you need that include in ispccdc.c? Yes, I started from a 100% clean build + tree. Without that change, I get a compile error. With it, and the TVP patches, I can now grab some video from my camera. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using get_scatterlist and put_scatterlist operations. Atleast one 'attach()' call is required to be made prior to calling the get_scatterlist() operation. Couple of building blocks in get_scatterlist() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. Why is this needed? it really doesn't make sense to be mmaping objects independent of some front-end like drm or v4l. how will you know what contents are in them, how will you synchronise access. Unless someone has a hard use-case for this I'd say we drop it until someone does. Dave. -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 7:41 AM, Dave Airlie airl...@gmail.com wrote: On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal sumit.sem...@ti.com wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using get_scatterlist and put_scatterlist operations. Atleast one 'attach()' call is required to be made prior to calling the get_scatterlist() operation. Couple of building blocks in get_scatterlist() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. mmap() file operation is provided for the associated 'fd', as wrapper over the optional allocator defined mmap(), to be used by devices that might need one. Why is this needed? it really doesn't make sense to be mmaping objects independent of some front-end like drm or v4l. well, the mmap is actually implemented by the buffer allocator (v4l/drm).. although not sure if this was the point how will you know what contents are in them, how will you synchronise access. Unless someone has a hard use-case for this I'd say we drop it until someone does. The intent was that this is for well defined formats.. ie. it would need to be a format that both v4l and drm understood in the first place for sharing to make sense at all.. Anyways, the basic reason is to handle random edge cases where you need sw access to the buffer. For example, you are decoding video and pull out a frame to generate a thumbnail w/ a sw jpeg encoder.. On gstreamer 0.11 branch, for example, there is already a map/unmap virtual method on the gst buffer for sw access (ie. same purpose as PrepareAccess/FinishAccess in EXA). The idea w/ dmabuf mmap() support is that we could implement support to mmap()/munmap() before/after sw access. With this current scheme, synchronization could be handled in dmabufops-mmap() and vm_ops-close().. it is perhaps a bit heavy to require mmap/munmap for each sw access, but I suppose this isn't really for the high-performance use case. It is just so that some random bit of sw that gets passed a dmabuf handle without knowing who allocated it can have sw access if really needed. BR, -R Dave. -- 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: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
well, the mmap is actually implemented by the buffer allocator (v4l/drm).. although not sure if this was the point Then why not use the correct interface? doing some sort of not-quite generic interface isn't really helping anyone except adding an ABI that we have to support. If someone wants to bypass the current kernel APIs we should add a new API for them not shove it into this generic buffer sharing layer. The intent was that this is for well defined formats.. ie. it would need to be a format that both v4l and drm understood in the first place for sharing to make sense at all.. How will you know the stride to take a simple example? The userspace had to create this buffer somehow and wants to share it with something, you sound like you really needs another API that is a simple accessor API that can handle mmaps. Anyways, the basic reason is to handle random edge cases where you need sw access to the buffer. For example, you are decoding video and pull out a frame to generate a thumbnail w/ a sw jpeg encoder.. Again, doesn't sound like it should be part of this API, and also sounds like the sw jpeg encoder will need more info about the buffer anyways like stride and format. With this current scheme, synchronization could be handled in dmabufops-mmap() and vm_ops-close().. it is perhaps a bit heavy to require mmap/munmap for each sw access, but I suppose this isn't really for the high-performance use case. It is just so that some random bit of sw that gets passed a dmabuf handle without knowing who allocated it can have sw access if really needed. So I think thats fine, write a sw accessor providers, don't go overloading the buffer sharing code. This API will limit what people can use this buffer sharing for with pure hw accessors, you might say, oh buts its okay to fail the mmap then, but the chances of sw handling that I'm not so sure off. Dave. -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 8:35 AM, Dave Airlie airl...@gmail.com wrote: well, the mmap is actually implemented by the buffer allocator (v4l/drm).. although not sure if this was the point Then why not use the correct interface? doing some sort of not-quite generic interface isn't really helping anyone except adding an ABI that we have to support. But what if you don't know who allocated the buffer? How do you know what interface to use to mmap? If someone wants to bypass the current kernel APIs we should add a new API for them not shove it into this generic buffer sharing layer. The intent was that this is for well defined formats.. ie. it would need to be a format that both v4l and drm understood in the first place for sharing to make sense at all.. How will you know the stride to take a simple example? The userspace had to create this buffer somehow and wants to share it with something, you sound like you really needs another API that is a simple accessor API that can handle mmaps. Well, things like stride, width, height, color format, userspace needs to know all this already, even for malloc()'d sw buffers. The assumption is userspace already has a way to pass this information around so it was not required to be duplicated by dmabuf. Anyways, the basic reason is to handle random edge cases where you need sw access to the buffer. For example, you are decoding video and pull out a frame to generate a thumbnail w/ a sw jpeg encoder.. Again, doesn't sound like it should be part of this API, and also sounds like the sw jpeg encoder will need more info about the buffer anyways like stride and format. With this current scheme, synchronization could be handled in dmabufops-mmap() and vm_ops-close().. it is perhaps a bit heavy to require mmap/munmap for each sw access, but I suppose this isn't really for the high-performance use case. It is just so that some random bit of sw that gets passed a dmabuf handle without knowing who allocated it can have sw access if really needed. So I think thats fine, write a sw accessor providers, don't go overloading the buffer sharing code. But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? This API will limit what people can use this buffer sharing for with pure hw accessors, you might say, oh buts its okay to fail the mmap then, but the chances of sw handling that I'm not so sure off. I'm not entirely sure the case you are worried about.. sharing buffers between multiple GPU's that understand same tiled formats? I guess that is a bit different from a case like a jpeg encoder that is passed a dmabuf handle without any idea where it came from.. I guess if sharing a buffer between multiple drm devices, there is nothing stopping you from having some NOT_DMABUF_MMAPABLE flag you pass when the buffer is allocated, then you don't have to support dmabuf-mmap(), and instead mmap via device and use some sort of DRM_CPU_PREP/FINI ioctls for synchronization.. BR, -R Dave. -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. mmap just feels wrong in this API, which is a buffer sharing API not a buffer mapping API. I guess if sharing a buffer between multiple drm devices, there is nothing stopping you from having some NOT_DMABUF_MMAPABLE flag you pass when the buffer is allocated, then you don't have to support dmabuf-mmap(), and instead mmap via device and use some sort of DRM_CPU_PREP/FINI ioctls for synchronization.. Or we could make a generic CPU accessor that we don't have to worry about. Dave. -- 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
Controlling external GPIO in IVC-200G board
Hi there, we recently purchased a IVC-200G board from IEI: http://ieiworld.com/product_groups/industrial/content.aspx?gid=09049535992720993533cid=09049577938864496628id=08142301152930771045 we would like to use the external GPIO capabilities of such board on Linux. This external GPIO is used to control external devices, such as lights, gates, doors, ... We already asked for support from the vendor, but they suggested us to use the Windows SDK :(, so we hope that some one in this list have some knowledge about the board and can help us. We are using a quite recent version of Linux Kernel (2.6.35.11) and the bttv module is working correctly for what concerns video capturing. Now we would like to control the external GPIO embedded in the IVC-200G board, but we don't know how to do it. In the driver CD provided with the board we found a directory Linux, containing three subdirectories: Demo, Driver and Sdk: The Demo directory contains a demo program which demonstrates how to capture video with the IVC-200G board, but doesn't help to understand how to control the external GPIO. The Driver directory contains some very old _binary_ bttv drivers (specific for Red Hat 7.2, 7.3 and 8 versions), but this is not useful for our purpose. The Sdk directory contains only a C header file (ieibt878.h, pasted here http://pastebin.com/cjezwusy) and a text file sdk-howto (pasted here http://pastebin.com/H66WzF1G). The section 4 of sdk-howto explains something related to external GPIO, for example we can read To set GPIO outputs, use structure iei_gpio and VIDIOC_IEI_SET_GPIO ioctl call, but it's not clear on which device (we mean which node in /dev directory) we should perform the ioctl call. Can you help us in using the external GPIO in the IVC-200G board on Linux? Thank you very much for your help! -- Augusto Destrero, PhD -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote: But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. oh, ok, so you are talking about a kernel level interface, rather than userspace.. but I guess in this case I don't quite see the difference. It amounts to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd directly then you don't have to pass around a 2nd fd. [*] there is nothing stopping defining some dmabuf ioctls (such as for synchronization).. although the thinking was to keep it simple for first version of dmabuf BR, -R mmap just feels wrong in this API, which is a buffer sharing API not a buffer mapping API. I guess if sharing a buffer between multiple drm devices, there is nothing stopping you from having some NOT_DMABUF_MMAPABLE flag you pass when the buffer is allocated, then you don't have to support dmabuf-mmap(), and instead mmap via device and use some sort of DRM_CPU_PREP/FINI ioctls for synchronization.. Or we could make a generic CPU accessor that we don't have to worry about. Dave. -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote: On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote: But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. oh, ok, so you are talking about a kernel level interface, rather than userspace.. but I guess in this case I don't quite see the difference. It amounts to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd directly then you don't have to pass around a 2nd fd. [*] there is nothing stopping defining some dmabuf ioctls (such as for synchronization).. although the thinking was to keep it simple for first version of dmabuf Yes a separate kernel level interface. Well I'd like to keep it even simpler. dmabuf is a buffer sharing API, shoehorning in a sw mapping API isn't making it simpler. The problem I have with implementing mmap on the sharing fd, is that nothing says this should be purely optional and userspace shouldn't rely on it. In the Intel GEM space alone you have two types of mapping, one direct to shmem one via GTT, the GTT could be even be a linear view. The intel guys initially did GEM mmaps direct to the shmem pages because it seemed simple, up until they had to do step two which was do mmaps on the GTT copy and ended up having two separate mmap methods. I think the problem here is it seems deceptively simple to add this to the API now because the API is simple, however I think in the future it'll become a burden that we'll have to workaround. Dave. -- 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: Controlling external GPIO in IVC-200G board
On Wed, Oct 12, 2011 at 04:03:46PM +0200, Augusto Destrero wrote: Hi there, Hi, Now we would like to control the external GPIO embedded in the IVC-200G board, but we don't know how to do it. bttv driver does not expose GPIOs to the userspace but I expect it can be modified to do so. Have a look at the GPIO_BT8XX driver to see how to do. Beware that GPIO_BT8XX is thought to drive physically altered boards (hence not working as brand new product - read the help message of the driver) while the bttv one has to keep all the other functionalities, so you may have less GPIO to play with because some are wired to something on the board itself. cheers, Domenico -- 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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 03:34:54PM +0100, Dave Airlie wrote: On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote: On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote: But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. oh, ok, so you are talking about a kernel level interface, rather than userspace.. but I guess in this case I don't quite see the difference. It amounts to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd directly then you don't have to pass around a 2nd fd. [*] there is nothing stopping defining some dmabuf ioctls (such as for synchronization).. although the thinking was to keep it simple for first version of dmabuf Yes a separate kernel level interface. Well I'd like to keep it even simpler. dmabuf is a buffer sharing API, shoehorning in a sw mapping API isn't making it simpler. The problem I have with implementing mmap on the sharing fd, is that nothing says this should be purely optional and userspace shouldn't rely on it. In the Intel GEM space alone you have two types of mapping, one direct to shmem one via GTT, the GTT could be even be a linear view. The intel guys initially did GEM mmaps direct to the shmem pages because it seemed simple, up until they had to do step two which was do mmaps on the GTT copy and ended up having two separate mmap methods. I think the problem here is it seems deceptively simple to add this to the API now because the API is simple, however I think in the future it'll become a burden that we'll have to workaround. Yeah, that's my feeling, too. Adding mmap sounds like a neat, simple idea, that could simplify things for simple devices like v4l. But as soon as you're dealing with a real gpu, nothing is simple. Those who don't believe this, just take a look at the data upload/download paths in the open-source i915,nouveau,radeon drivers. Making this fast (and for gpus, it needs to be fast) requires tons of tricks, special-cases and jumping through loops. You absolutely want the device-specific ioctls to do that. Adding a generic mmap just makes matters worse, especially if userspace expects this to work synchronized with everything else that is going on. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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 1/4] v4l: add support for selection api
On 10/12/2011 01:48 PM, Sakari Ailus wrote:
Hi Tomasz,
On Wed, Aug 31, 2011 at 02:28:20PM +0200, Tomasz Stanislawski wrote:
...
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..b7471fe 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,48 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
A minor comment. If the patches have not been pulled yet, how about adding
FLAG_ to the flag names? I.e. V4L2_SEL_FLAG_SIZE_GE and
V4L2_SEL_FLAG_SIZE_LE.
Hi Sakari,
The idea is good. I preferred to avoid using long names if possible.
I agree that using _FLAGS_ produce more informative name.
I'll fix it in the new version of selection API.
Regards,
Tomasz Stanislawski
Kind regards,
--
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] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Oct 12, 2011 at 9:34 AM, Dave Airlie airl...@gmail.com wrote: On Wed, Oct 12, 2011 at 3:24 PM, Rob Clark robdcl...@gmail.com wrote: On Wed, Oct 12, 2011 at 9:01 AM, Dave Airlie airl...@gmail.com wrote: But then we'd need a different set of accessors for every different drm/v4l/etc driver, wouldn't we? Not any more different than you need for this, you just have a new interface that you request a sw object from, then mmap that object, and underneath it knows who owns it in the kernel. oh, ok, so you are talking about a kernel level interface, rather than userspace.. but I guess in this case I don't quite see the difference. It amounts to which fd you call mmap (or ioctl[*]) on.. If you use the dmabuf fd directly then you don't have to pass around a 2nd fd. [*] there is nothing stopping defining some dmabuf ioctls (such as for synchronization).. although the thinking was to keep it simple for first version of dmabuf Yes a separate kernel level interface. I'm not against it, but if it is a device-independent interface, it just seems like six of one, half-dozen of the other.. Ie. how does it differ if the dmabuf fd is the fd used for ioctl/mmap, vs if some other /dev/buffer-sharer file that you open? But I think maybe I'm misunderstanding what you have in mind? BR, -R Well I'd like to keep it even simpler. dmabuf is a buffer sharing API, shoehorning in a sw mapping API isn't making it simpler. The problem I have with implementing mmap on the sharing fd, is that nothing says this should be purely optional and userspace shouldn't rely on it. In the Intel GEM space alone you have two types of mapping, one direct to shmem one via GTT, the GTT could be even be a linear view. The intel guys initially did GEM mmaps direct to the shmem pages because it seemed simple, up until they had to do step two which was do mmaps on the GTT copy and ended up having two separate mmap methods. I think the problem here is it seems deceptively simple to add this to the API now because the API is simple, however I think in the future it'll become a burden that we'll have to workaround. Dave. -- 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: vb2: add a check for uninitialized buffer
__buffer_in_use() might be called for empty/uninitialized buffer in the
following scenario: REQBUF(n, USER_PTR), QUERYBUF(). This patch fixes
kernel ops in such case.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/videobuf2-core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index d8affb8..cdbbab7 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -284,14 +284,14 @@ static bool __buffer_in_use(struct vb2_queue *q, struct
vb2_buffer *vb)
{
unsigned int plane;
for (plane = 0; plane vb-num_planes; ++plane) {
+ void mem_priv = vb-planes[plane].mem_priv;
/*
* If num_users() has not been provided, call_memop
* will return 0, apparently nobody cares about this
* case anyway. If num_users() returns more than 1,
* we are not the only user of the plane's memory.
*/
- if (call_memop(q, plane, num_users,
- vb-planes[plane].mem_priv) 1)
+ if (mem_priv call_memop(q, plane, num_users, mem_priv) 1)
return true;
}
return false;
--
1.7.1.569.g6f426
--
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 1/4] v4l: add support for selection api
On Wed, Oct 12, 2011 at 05:08:20PM +0200, Tomasz Stanislawski wrote:
On 10/12/2011 01:48 PM, Sakari Ailus wrote:
Hi Tomasz,
On Wed, Aug 31, 2011 at 02:28:20PM +0200, Tomasz Stanislawski wrote:
...
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..b7471fe 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -738,6 +738,48 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_SIZE_GE 0x0001
+#define V4L2_SEL_SIZE_LE 0x0002
A minor comment. If the patches have not been pulled yet, how about adding
FLAG_ to the flag names? I.e. V4L2_SEL_FLAG_SIZE_GE and
V4L2_SEL_FLAG_SIZE_LE.
Hi Sakari,
The idea is good. I preferred to avoid using long names if possible.
I agree that using _FLAGS_ produce more informative name.
I'll fix it in the new version of selection API.
Thanks, Thomasz! (I propose FLAG and not FLAGS since it's a single
flag.)
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Oct 12 19:00:15 CEST 2011 git hash:e30528854797f057aa6ffb6dc9f890e923c467fd gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 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: WARNINGS 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-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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 linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: OMAP3 ISP ghosting
On 2011-10-11 07:20, Gary Thomas wrote:
As a number of us have seen, when using the OMAP3 ISP with a BT-656
sensor, e.g. TVP5150, the results are not 100% correct. Some number
of frames (typically 2) will be correct, followed by another set (3)
which are incorrect and show only partially correct data. Note: I
think the numbers (2 correct, 3 wrong) are not cast in stone and may
be related to some other factors like number of buffers in use, etc.
Anyway, I've observed that in the incorrect frames, 1/2 the data is
correct (even lines?) and the other 1/2 is wrong. One of my customers
pointed out that it looks like the incorrect data is just what was
left in memory during some previous frame. I'd like to prove this
by zeroing the entire frame data memory before the frame is captured.
That way, there won't be stale data from a previous frame, but null
data which should show up strongly when examined. Does anyone in this
group have a suggestion the best way/place to do this?
Final question: given a properly connected TVP5150-CCDC, including
all SYNC signals, could this setup be made to work in RAW, non BT-656
mode? My board at least has all of these signals routed, so it should
just be a matter of configuring the software...
Any ideas on this? My naive attempt (diffs attached) just hangs up.
These changes disable BT-656 mode in the CCDC and tell the TVP5150
to output raw YUV 4:2:2 data including all SYNC signals.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
diff --git a/arch/arm/mach-omap2/board-cobra3530p60.c
b/arch/arm/mach-omap2/board-cobra3530p60.c
index a8e8f21..5e97838 100644
--- a/arch/arm/mach-omap2/board-cobra3530p60.c
+++ b/arch/arm/mach-omap2/board-cobra3530p60.c
@@ -480,6 +480,6 @@ static struct isp_v4l2_subdevs_group
cobra3530p60_camera_subdevs[] = {
.data_lane_shift = 0,
.clk_pol = 1,
-.bt656 = 1,
+.bt656 = 0,
.fldmode = 1,
}
},
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index f4a66c7..26360ae 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -499,7 +499,7 @@ static const struct i2c_reg_value tvp5150_init_enable[] = {
},{ /* Activates video std autodetection for all standards */
TVP5150_AUTOSW_MSK, 0x0
},{ /* Default format: 0x47. For 4:2:2: 0x40 */
- TVP5150_DATA_RATE_SEL, 0x47
+ TVP5150_DATA_RATE_SEL, 0x40 /*0x47*/
},{
TVP5150_CHROMA_PROC_CTL_1, 0x0c
},{
@@ -993,7 +993,7 @@ static int tvp515x_s_stream(struct v4l2_subdev *subdev, int
enable)
/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
if (enable)
- tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09);
+ tvp5150_write(subdev, TVP5150_MISC_CTL, 0x09+0x04);
else
tvp5150_write(subdev, TVP5150_MISC_CTL, 0x00);
[PATCH] [media] videodev: fix a NULL pointer dereference in v4l2_device_release()
The change in 8280b66 does not cover the case when v4l2_dev is already NULL, fix that. With a Kinect sensor, seen as an USB camera using GSPCA in this context, a NULL pointer dereference BUG can be triggered by just unplugging the device after the camera driver has been loaded. Signed-off-by: Antonio Ospite osp...@studenti.unina.it --- Hi, can anyone reproduce this? This is the complete trace, I left it out of the commit message, but feel free to include it if you think it is worth it. BUG: unable to handle kernel NULL pointer dereference at 0090 IP: [a10cc604] v4l2_device_release+0xb8/0xe8 [videodev] PGD 0 Oops: [#1] SMP CPU 0 Modules linked in: snd_usb_audio snd_usbmidi_lib gspca_kinect gspca_main videodev media v4l2_compat_ioctl32 hidp snd_hrtimer ebtable_nat ebtables powernow_k8 mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace ipt_MASQUERADE xt_CHECKSUM bridge stp ppdev lp bnep rfcomm tun sit tunnel4 ip6table_raw ip6table_mangle ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt ip6table_filter ip6_tables decnet binfmt_misc uinput fuse xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_raw ip_tables x_tables nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc it87 hwmon_vid loop kvm_amd kvm snd_hda_codec_hdmi snd_hda_codec_via nvidia(P) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi cryptd aes_x86_64 snd_seq_midi_event aes_generic ecb snd_seq btusb bluetooth evdev snd_timer snd_seq_device edac_core parport_pc pcspkr parport rfkill snd edac_mce_amd k8temp crc16 soundcore mxm_wmi snd_page_alloc asus_atk0110 shpchp video pci_hotplug i2c_nforce2 wmi i2c_core processor thermal_sys button ext3 jbd mbcache dm_mod sg sd_mod sr_mod crc_t10dif cdrom ata_generic usb_storage usbhid hid uas ahci libahci pata_amd libata scsi_mod forcedeth floppy ohci_hcd ehci_hcd usbcore [last unloaded: scsi_wait_scan] Pid: 125, comm: khubd Tainted: P3.1.0-rc9-ao2 #3 System manufacturer System Product Name/M3N78-VM RIP: 0010:[a10cc604] [a10cc604] v4l2_device_release+0xb8/0xe8 [videodev] RSP: 0018:88011639fc10 EFLAGS: 00010246 RAX: RBX: 8800ca61a088 RCX: 0001 RDX: 0001 RSI: RDI: a10db000 RBP: R08: 8119b320 R09: 8119b320 R10: 0001 R11: 0001 R12: 8800ca61a000 R13: 8164ffb0 R14: R15: 001f FS: 7f61275f37a0() GS:88011fc0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0090 CR3: 0001150de000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process khubd (pid: 125, threadinfo 88011639e000, task 88011639d590) Stack: 8800ca5d8380 8800ca61a098 8800ca66c200 81232e94 8800ca61a0d0 8119a7fa 8119b320 8800ca61a0d0 8119a7ab 8800ca56dc00 a10e1068 8119b93a Call Trace: [81232e94] ? device_release+0x41/0x72 [8119a7fa] ? kobject_release+0x4f/0x6c [8119b320] ? add_uevent_var+0xdc/0xdc [8119a7ab] ? kobject_del+0x2d/0x2d [8119b93a] ? kref_put+0x3e/0x47 [a0039f15] ? usb_unbind_interface+0x4d/0x111 [usbcore] [81235b9b] ? __device_release_driver+0x7d/0xc9 [81235c02] ? device_release_driver+0x1b/0x27 [81235804] ? bus_remove_device+0x7c/0x8b [812337e6] ? device_del+0x129/0x177 [a00384f7] ? usb_disable_device+0x6a/0x159 [usbcore] [a003250c] ? usb_disconnect+0x8c/0x108 [usbcore] [a00324ed] ? usb_disconnect+0x6d/0x108 [usbcore] [a0033bc5] ? hub_thread+0x58e/0xec6 [usbcore] [81036e08] ? set_next_entity+0x32/0x52 [8105ec53] ? add_wait_queue+0x3c/0x3c [a0033637] ? usb_remote_wakeup+0x2f/0x2f [usbcore] [8105e60d] ? kthread+0x76/0x7e [81332f34] ? kernel_thread_helper+0x4/0x10 [8105e597] ? kthread_worker_fn+0x139/0x139 [81332f30] ? gs_change+0x13/0x13 Code: 0d a1 e8 7a ec 25 e0 48 8b 83 78 02 00 00 48 85 c0 74 18 48 83 78 08 00 74 11 83 bb b0 02 00 00 03 74 08 4c 89 e7 e8 03 5a ff ff 83 bd 90 00 00 00 00 b8 00 00 00 00 4c 89 e7 48 0f 44 e8 ff RIP [a10cc604] v4l2_device_release+0xb8/0xe8 [videodev] RSP 88011639fc10 CR2: 0090 ---[ end trace 99f7feddc91f30d6 ]--- Thanks, Antonio Ospite http://ao2.it drivers/media/video/v4l2-dev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index d721565..a5c9ed1 100644 --- a/drivers/media/video/v4l2-dev.c +++
[PATCH] media: tea5764: reconcile Kconfig symbol and macro
The Kconfig symbol RADIO_TEA5764_XTAL is unused. The code does use a
RADIO_TEA5764_XTAL macro, but does that rather peculiar. But there seems
to be a way to keep both. (The easiest way out would be to rip out both
the Kconfig symbol and the macro.)
Note there's also a module parameter 'use_xtal' to influence all this.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
I didn't dare to submit this a trivial patch. This is still untested. By
the way, is xtal a common abbreviation of crystal?
drivers/media/radio/radio-tea5764.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 95ddcc4..db20904 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -128,8 +128,10 @@ struct tea5764_write_regs {
u16 rdsbbl; /* PAUSEDET RDSBBL */
} __attribute__ ((packed));
-#ifndef RADIO_TEA5764_XTAL
+#ifdef CONFIG_RADIO_TEA5764_XTAL
#define RADIO_TEA5764_XTAL 1
+#else
+#define RADIO_TEA5764_XTAL 0
#endif
static int radio_nr = -1;
--
1.7.4.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: [RFC 2/2] dma-buf: Documentation for buffer sharing framework
On 10/11/2011 02:23 AM, Sumit Semwal wrote: Add documentation for dma buffer sharing framework, explaining the various operations, members and API of the dma buffer sharing framework. Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- Documentation/dma-buf-sharing.txt | 210 + 1 files changed, 210 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sharing.txt diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt new file mode 100644 index 000..4da6644 --- /dev/null +++ b/Documentation/dma-buf-sharing.txt @@ -0,0 +1,210 @@ +DMA Buffer Sharing API Guide + + +Sumit Semwal +sumit dot semwal at linaro dot org + sumit dot semwal at ti dot com + +This document serves as a guide to device-driver writers on what is the dma-buf +buffer sharing API, how to use it for exporting and using shared buffers. + +Any device driver which wishes to be a part of dma buffer sharing, can do so as Please use DMA instead of dma (except combinations like dma-buf are OK). [multiple] +either the 'exporter' of buffers, or the 'user' of buffers. + +Say a driver A wants to use buffers created by driver B, then we call B as the +exporter, and B as buffer-user. and A + +The exporter +- implements and manages operations[1] for the buffer +- allows other users to share the buffer by using dma_buf sharing APIs, +- manages the details of buffer allocation, +- decides about the actual backing storage where this allocation happens, +- takes care of any migration of scatterlist - for all (shared) users of this + buffer, +- optionally, provides mmap capability for drivers that need it. + +The buffer-user +- is one of (many) sharing users of the buffer. +- doesn't need to worry about how the buffer is allocated, or where. +- needs a mechanism to get access to the scatterlist that makes up this buffer + in memory, mapped into its own address space, so it can access the same area + of memory. + + +The dma_buf buffer sharing API usage contains the following steps: + +1. Exporter announces that it wishes to export a buffer +2. Userspace gets the file descriptor associated with the exported buffer, and + passes it around to potential buffer-users based on use case +3. Each buffer-user 'connects' itself to the buffer +4. When needed, buffer-user requests access to the buffer from exporter +5. When finished with its use, the buffer-user notifies end-of-dma to exporter +6. when buffer-user is done using this buffer completely, it 'disconnects' + itself from the buffer. + + +1. Exporter's announcement of buffer export + + The buffer exporter announces its wish to export a buffer. In this, it + connects its own private buffer data, provides implementation for operations + that can be performed on the exported dma_buf, and flags for the file + associated with this buffer. + + Interface: + struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops, +int flags) + + If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a + pointer to the same. It also associates an anon file with this buffer, so it s/anon/anonymous/ (multiple) + can be exported. On failure to allocate the dma_buf object, it returns NULL. + +2. Userspace gets a handle to pass around to potential buffer-users + + Userspace entity requests for a file-descriptor (fd) which is a handle to the + anon file associated with the buffer. It can then share the fd with other + drivers and/or processes. + + Interface: + int dma_buf_fd(struct dma_buf *dmabuf) + + This API installs an fd for the anon file associated with this buffer; + returns either 'fd', or error. + +3. Each buffer-user 'connects' itself to the buffer + + Each buffer-user now gets a reference to the buffer, using the fd passed to + it. + + Interface: + struct dma_buf *dma_buf_get(int fd) + + This API will return a reference to the dma_buf, and increment refcount for + it. + + After this, the buffer-user needs to attach its device with the buffer, which + helps the exporter to know of device buffer constraints. + + Interface: + struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, +struct device *dev) + + This API returns reference to an attachment structure, which is then used + for scatterlist operations. It will optionally call the 'attach' dma_buf + operation, if provided by the exporter. + + The dma-buf sharing framework does the book-keeping bits related to keeping
where is the cx23887 module in kernel-3.04 config?
Where is the cx23887 module in the kernel-3.04 config? I'm trying to get a Hauppauge WinTV-HVR-1250 working. -- 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: where is the cx23887 module in kernel-3.04 config?
On 10/12/11 16:30, James wrote: Where is the cx23887 module in the kernel-3.04 config? I'm trying to get a Hauppauge WinTV-HVR-1250 working. -- 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 Found it under video4lnux driver and not DVB/ATSC adapters (which seems more logical). -- 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: where is the cx23887 module in kernel-3.04 config?
On Wed, Oct 12, 2011 at 4:42 PM, James bjloc...@lockie.ca wrote: On 10/12/11 16:30, James wrote: Where is the cx23887 module in the kernel-3.04 config? I'm trying to get a Hauppauge WinTV-HVR-1250 working. -- 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 Found it under video4lnux driver and not DVB/ATSC adapters (which seems more logical). In general, everything that is a hybrid card is under media/video. That's just a product of the way the two trees evolved (v4l vs. dvb)... Steven actually has a tree which I believe has support for pretty much every 1250 variant. It's not merged upstream though, so you will likely have to do some tweaking of the code to make it work with current kernels. http://kernellabs.com/hg/~stoth/cx23888-encoder/ 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: digital tuner
On Thu, May 12, 2011 at 3:49 PM, James bjloc...@lockie.ca wrote: I have an analog: Hauppauge WinTV-Go PLUS which has a lineout. I'm considering a digital card. The Hauppauge WinTV-HVR-1250 does NOT have a lineout so how does it do sound? Does PCIe pass through the sound to the OS sound system? I read on the linuxtv wiki that only the digital works on this card. You've probably already figured this out by now, but the cx23885 does have an ALSA driver, which isn't yet upstream. Igor actually just rebased Steven's tree with the support against the latest kernel, so hopefully it will make it upstream soon (see the linux-media mailing list for the last couple of days to find the thread). 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: [RFC 2/2] dma-buf: Documentation for buffer sharing framework
Hi Randy,
On Thu, Oct 13, 2011 at 4:00 AM, Randy Dunlap rdun...@xenotime.net wrote:
On 10/11/2011 02:23 AM, Sumit Semwal wrote:
Add documentation for dma buffer sharing framework, explaining the
various operations, members and API of the dma buffer sharing
framework.
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
Documentation/dma-buf-sharing.txt | 210
+
snip
+ if the new buffer-user has stricter 'backing-storage constraints', and
the
+ exporter can handle these constraints, the exporter can just stall on
the
+ get_scatterlist till all outstanding access is completed (as signalled
by
until
Thanks for your review; I will update all these in the next version.
+ put_scatterlist).
+ Once all ongoing access is completed, the exporter could potentially
move
+ the buffer to the stricter backing-storage, and then allow further
+ {get,put}_scatterlist operations from any buffer-user from the migrated
+ backing-storage.
+
+ If the exporter cannot fulfill the backing-storage constraints of the new
+ buffer-user device as requested, dma_buf_attach() would return an error
to
+ denote non-compatibility of the new buffer-sharing request with the
current
+ buffer.
+
+ If the exporter chooses not to allow an attach() operation once a
+ get_scatterlist has been called, it simply returns an error.
+
+- mmap file operation
+ An mmap() file operation is provided for the fd associated with the
buffer.
+ If the exporter defines an mmap operation, the mmap() fop calls this to
allow
+ mmap for devices that might need it; if not, it returns an error.
+
+References:
+[1] struct dma_buf_ops in include/linux/dma-buf.h
+[2] All interfaces mentioned above defined in include/linux/dma-buf.h
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Best regards,
~Sumit.
--
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
