RE: vb2: about vb2_queue-queued_count
Hello, On Friday, June 10, 2011 6:29 PM Uwe Kleine-König wrote: On Fri, Jun 10, 2011 at 01:50:37PM +0200, Marek Szyprowski wrote: Hello, On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote: I'm still debugging my new video overlay device driver. The current problem is again when playing back a second video. After streamoff is called at the end of the first video, I disable the overlay and call vb2_buffer_done on the last buffer. This is exited early because vb-state == VB2_BUF_STATE_DEQUEUED. This results in vb-vb2_queue-queued_count being 1. Now if the new video starts I call vb2_queue_init in the .vidioc_reqbufs callback on my queue (that still has queued_count == 1). After vb2_queue_init returns queued_count is still 1 though q-queued_list is reset to be empty. __vb2_queue_cancel has a similar problem, q-queued_list is reset, but queued_count is not. Thanks again for finding the bug. You are right, __vb2_queue_cancel should reset queued_count too. I will post a patch soon. IMHO vb2_queue_init should reset queued_count, too. Not sure if you just skipped to mention it here vb2_queue_init assumes that the called allocated vb2_queue with kzalloc() or did memset(q, 0, sizeof(struct vb2_queue)), so it is not really required to explicitly set queued_count to zero. 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: soc_camera_set_fmt in soc_camera_open
On Mon, 13 Jun 2011, Kassey Lee wrote: On Fri, Jun 10, 2011 at 5:16 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 10 Jun 2011, Kassey Lee wrote: hi, Guennadi: in drivers/media/video/soc_camera.c static int soc_camera_open(struct file *file) it will call soc_camera_set_fmt to configure the sensor and host controller. for sensor, this means it will trigger download setting, this may take quite time through i2c or SPI. I complain about this, because after we open, request, s_param, S_FMT, DQBUF, in S_FMT, we will download the setting again. how do you think ? If it's a concern for you, you might consider moving most of your sensor set up from .s_(mbus_)fmt() to .s_stream(). Would that solve your problem? .s_stream can not pass the fmt info, because we need download different setting depends on the format(UYVY, resolution, JPEG) Of course it cannot. You would have to store it in your .s_(mbus_)fmt() method and use during .s_stream(). what I can figure out in open is power up sensor, why we need to .s_fmt() in open ? The ideas behind this decision were to (1) make it simple for the drivers to comply with the specification's requirements to preserve the configuration across close() / open() calls, to be able to start streaming data directly after open() without any S_FMT ioctl()s, and to allow the hardware to be powered down when unused, and to (2) initialise internal format translation tables and other data. We could try to slightly optimise this by only calling soc_camera_set_fmt() during STREAMON _if_ no S_FMT has been called explicitly. But that would be a larger change, than just adjusting your driver. You could do another optimisation yourself too: if the new configuration is equal to the currently configured one, you don't issue any i2c commands. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP_VOUT: Create separate file for VRFB related API's
On Monday 13 June 2011 10:13 AM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Monday, June 13, 2011 10:17 AM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org Subject: Re: [PATCH 2/2] OMAP_VOUT: Create separate file for VRFB related API's Hi Vaibhav, On Friday 27 May 2011 12:31 PM, Taneja, Archit wrote: Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's, making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS, since OMAP4 doesn't have VRFB block. Added new enum vout_rotation_type and rotation_type member to omapvideo_info, this is initialized based on the arch type in omap_vout_probe. The rotation_type var is now used to choose between vrfb and non-vrfb calls. Any comments on this patch? Archit, Last week I had to park this due to some high priority issue, today I am going to validate these patches and will respond you. Code implementation point of view, this patch looks ok. And I believe you will incorporate my comments on first patch. Oh okay, great. Thanks, Archit -- 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: vb2: about vb2_queue-queued_count
Hello, On Mon, Jun 13, 2011 at 08:26:13AM +0200, Marek Szyprowski wrote: On Friday, June 10, 2011 6:29 PM Uwe Kleine-König wrote: On Fri, Jun 10, 2011 at 01:50:37PM +0200, Marek Szyprowski wrote: Hello, On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote: I'm still debugging my new video overlay device driver. The current problem is again when playing back a second video. After streamoff is called at the end of the first video, I disable the overlay and call vb2_buffer_done on the last buffer. This is exited early because vb-state == VB2_BUF_STATE_DEQUEUED. This results in vb-vb2_queue-queued_count being 1. Now if the new video starts I call vb2_queue_init in the .vidioc_reqbufs callback on my queue (that still has queued_count == 1). After vb2_queue_init returns queued_count is still 1 though q-queued_list is reset to be empty. __vb2_queue_cancel has a similar problem, q-queued_list is reset, but queued_count is not. Thanks again for finding the bug. You are right, __vb2_queue_cancel should reset queued_count too. I will post a patch soon. IMHO vb2_queue_init should reset queued_count, too. Not sure if you just skipped to mention it here vb2_queue_init assumes that the called allocated vb2_queue with kzalloc() or did memset(q, 0, sizeof(struct vb2_queue)), so it is not really required to explicitly set queued_count to zero. Hmmm, I call vb2_queue_init in the callback .vidioc_reqbufs, because AFAICT this is the only place where I get the needed info to set q-type. As this looks wrong now, can you hint where to initialize the queue instead? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: vb2: about vb2_queue-queued_count
Hello, On Monday, June 13, 2011 10:37 AM Uwe Kleine-König wrote: On Mon, Jun 13, 2011 at 08:26:13AM +0200, Marek Szyprowski wrote: On Friday, June 10, 2011 6:29 PM Uwe Kleine-König wrote: On Fri, Jun 10, 2011 at 01:50:37PM +0200, Marek Szyprowski wrote: Hello, On Wednesday, June 08, 2011 10:48 PM Uwe Kleine-König wrote: I'm still debugging my new video overlay device driver. The current problem is again when playing back a second video. After streamoff is called at the end of the first video, I disable the overlay and call vb2_buffer_done on the last buffer. This is exited early because vb-state == VB2_BUF_STATE_DEQUEUED. This results in vb-vb2_queue-queued_count being 1. Now if the new video starts I call vb2_queue_init in the .vidioc_reqbufs callback on my queue (that still has queued_count == 1). After vb2_queue_init returns queued_count is still 1 though q- queued_list is reset to be empty. __vb2_queue_cancel has a similar problem, q-queued_list is reset, but queued_count is not. Thanks again for finding the bug. You are right, __vb2_queue_cancel should reset queued_count too. I will post a patch soon. IMHO vb2_queue_init should reset queued_count, too. Not sure if you just skipped to mention it here vb2_queue_init assumes that the called allocated vb2_queue with kzalloc() or did memset(q, 0, sizeof(struct vb2_queue)), so it is not really required to explicitly set queued_count to zero. Hmmm, I call vb2_queue_init in the callback .vidioc_reqbufs, because AFAICT this is the only place where I get the needed info to set q-type. As this looks wrong now, can you hint where to initialize the queue instead? Huh, this design doesn't look good. vb2_queue_init should be called during driver initialization, and .videoc_reqbufs should be just a proxy to vb2_reqbus() (same with querybuf, qbuf, dqbuf, streamon, streamoff, read and poll). Why do you want to play with q-type? Can't you just set it correctly to V4L2_BUF_TYPE_VIDEO_CAPTURE in driver probe? 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: Improving kernel - userspace (usbfs) usb device hand off
Hi, On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote: there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). well, if the manufacturer doesn't want to implement UVC for whatever reason, it's his call ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
Hello, On Friday, June 10, 2011 6:22 PM Arnd Bergmann wrote: On Friday 10 June 2011, Marek Szyprowski wrote: The Contiguous Memory Allocator is a set of functions that lets one initialise a region of memory which then can be used to perform allocations of contiguous memory chunks from. CMA allows for creation of separate contexts. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for page cache when CMA devices do not use it. On cm_alloc() request such pages are migrated out of CMA area to free required contiguous block. Hi Marek, I'm generally happy with the patches 1 through 7, i.e the heavy lifting to make contiguous allocations work. Thank you very much for keeping up the work and submitting these in a good shape. I do think that we need to discuss the driver-visible API a bit more. My feeling is that this is rather un-Linux-like and it needs to be simplified some more. Of course, I don't mind being overruled by the memory management experts here, or if you can argue that it's really the right way to do it. Thanks for your comments! + * Driver usage + * + * CMA should not be used directly by the device drivers. It should + * be considered as helper framework for dma-mapping subsystm and + * respective (platform)bus drivers. + * + * The CMA client needs to have a pointer to a CMA context + * represented by a struct cma (which is an opaque data type). + * + * Once such pointer is obtained, a caller may allocate contiguous + * memory chunk using the following function: + * + * cm_alloc() + * + * This function returns a pointer to the first struct page which + * represent a contiguous memory chunk. This pointer + * may be used with the following function: + * + * cm_free()-- frees allocated contiguous memory Please explain why you want a new top-level API here. I think it would be much nicer if a device driver could simply call alloc_pages(..., GFP_CMA) or similar, where all the complexity in here gets hidden behind a conditional deep inside of the page allocator. Evidently, the two functions you describe here have an extra argument for the context. Can you elaborate why that is really needed? What is the specific requirement to have multiple such contexts in one system and what is the worst-case effect that you would get when the interface is simplified to have only one for all devices? Alternatively, would it be possible to provide the cm_alloc/cm_free functions only as backing to the dma mapping API and not export them as a generic device driver interface? cm_alloc/free are definitely not meant to be called from device drivers. They should be only considered as a backend for dma-mapping. 'Raw' contiguous memory block doesn't really make sense for the device drivers. What the drivers require is a contiguous memory block that is somehow mapped into respective bus address space, so dma-mapping framework is the right interface. alloc_pages(..., GFP_CMA) looks nice but in fact it is really impractical. The driver will need to map such buffer to dma context anyway, so imho dma_alloc_attributed() will give the drivers much more flexibility. In terms of dma-mapping the context argument isn't anything odd. If possible I would like to make cma something similar to declare_dma_coherent()friends, so the board/platform/bus startup code will just call declare_dma_contiguous() to enable support for cma for particular devices. + * Platform/machine integration + * + * CMA context must be created on platform or machine initialisation + * and passed to respective subsystem that will be a client for CMA. + * The latter may be done by a global variable or some filed in + * struct device. For the former CMA provides the following functions: + * + * cma_init_migratetype() + * cma_reserve() + * cma_create() + * + * The first one initialises a portion of reserved memory so that it + * can be used with CMA. The second first tries to reserve memory + * (using memblock) and then initialise it. + * + * The cma_reserve() function must be called when memblock is still + * operational and reserving memory with it is still possible. On + * ARM platform the reserve machine callback is a perfect place to + * call it. + * + * The last function creates a CMA context on a range of previously + * initialised memory addresses. Because it uses kmalloc() it needs + * to be called after SLAB is initialised. + */ This interface looks flawed to me for multiple reasons: * It requires you to call three distinct functions in order to do one thing, and they all take the same arguments (more or less). Why not have one function call at the latest possible point where you can still change the memory attributes, and have everything else happen automatically? Initialization
Re: Crash on unplug with the uvc driver in linuxtv/staging/for_v3.1
Hi Hans (and Hans), On Saturday 11 June 2011 11:16:10 Laurent Pinchart wrote: On Thursday 09 June 2011 13:22:03 Hans de Goede wrote: Hi, When I unplug a uvc camera *while streaming* I get: [15824.809741] BUG: unable to handle kernel NULL pointer dereference at (null) [snip] I've not tested if this also impacts 3.0!! It probably does. Thanks for the report. I'll fix it. It does. Fixing the problem turns to be more complex than expected. The crash is caused by media entities life time management issues. Entities associated with video device nodes are unregistered in video_unregister_device(). This removes the entity from its parent's entities list, and sets the entity's parent to NULL. Entities also get/put references to their parent's module through media_entity_get() and media_entity_put(). Those functions are called in the open and release handlers of video device nodes and subdev device nodes. The reason behind this is to avoid a parent module from being removed while a subdev is opened, as closing a subdev can call to the parent's module through board code. When a UVC device is unplugged while streaming, the uvcvideo driver will call video_unregister_device() in the disconnect handler. This will in turn call media_device_unregister_entity() which sets the entity's parent to NULL. When the user then closes open video device nodes, v4l2_release() calls media_entity_put() which tries to dereference entity-parent, and oopses. I've tried to move the media_device_unregister_entity() call from video_unregister_device() to v4l2_device_release() (called when the last reference to the video device is released). media_entity_put() is then called before the entity is unregistered, but that results in a different oops: as this happens after the USB disconnect callback is called, entity-parent-dev- driver is now NULL, and trying to access entity-parent-dev-driver-owner to decrement the module use count oopses. One possible workaround is to remove media_entity_get()/media_entity_put() calls from v4l2-dev.c. As the original purpose of those functions was to avoid a parent module from being removed while still accessible through board code, and all existing MC-enabled drivers register video device nodes with the owner equal to the entity's parent's module, we can safely do it. I'd rather implement a proper solution though, but that's not straightforward. We short-circuit the kernel reference management by going through board code. There's something fundamentally wrong in the way we manage subdevs and device/module reference counts. I'm not sure where the proper fix should go to though. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.0] videobuf2 fixes
Hello Mauro,
I’ve collected videobuf2 fixes and prepared a separate branch with them.
The following changes since commit 59c5f46fbe01a00eedf54a23789634438bb80603:
Linux 3.0-rc2 (2011-06-06 18:06:33 +0900)
are available in the git repository at:
git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2-fixes-for-3.0
Marek Szyprowski (3):
media: vb2: add __GFP_NOWARN to dma-sg allocator
Revert [media] v4l2: vb2: one more fix for REQBUFS()
media: vb2: reset queued_count value during queue reinitialization
drivers/media/video/videobuf2-core.c |8 +---
drivers/media/video/videobuf2-dma-sg.c |2 +-
2 files changed, 2 insertions(+), 8 deletions(-)
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
The above message is intended solely for the named addressee and may contain
trade secret, industrial technology or privileged and confidential information
otherwise protected under applicable law. Any unauthorized dissemination,
distribution, copying or use of the information contained in this communication
is strictly prohibited. If you have received this communication in error,
please notify sender by email and delete this communication immediately.
Powyższa wiadomość przeznaczona jest wyłącznie dla adresata niniejszej
wiadomości i może zawierać informacje będące tajemnicą handlową, tajemnicą
przedsiębiorstwa oraz informacje o charakterze poufnym chronione obowiązującymi
przepisami prawa. Jakiekolwiek nieuprawnione ich rozpowszechnianie,
dystrybucja, kopiowanie lub użycie informacji zawartych w powyższej wiadomości
jest zabronione. Jeśli otrzymałeś powyższą wiadomość omyłkowo, uprzejmie proszę
poinformuj o tym fakcie drogą mailową nadawcę tej wiadomości oraz niezwłocznie
usuń powyższą wiadomość ze swojego komputera.
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [RFCv4 PATCH 1/8] tuner-core: rename check_mode to supported_mode
On Monday, June 13, 2011 00:06:19 Mauro Carvalho Chehab wrote: Em 12-06-2011 15:09, Hans Verkuil escreveu: On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote: Em 12-06-2011 13:07, Hans Verkuil escreveu: On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote: Em 12-06-2011 07:59, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com The check_mode function checks whether a mode is supported. So calling it supported_mode is more appropriate. In addition it returned either 0 or -EINVAL which suggests that the -EINVAL error should be passed on. However, that's not the case so change the return type to bool. I prefer to keep returning -EINVAL. This is the proper thing to do, and to return the result to the caller. A fixme should be added though, so, after someone add a subdev call that would properly handle the -EINVAL code for multiple tuners, the functions should return the error code instead of 0. No, you can't return -EINVAL here. It is the responsibility of the bridge driver to determine whether there is e.g. a radio tuner. So if one of these tuner subdevs is called with mode radio while it is a tv tuner, then that is not an error, but instead it is a request that can safely be ignored as not relevant for that tuner. It is up to the bridge driver to ensure that a tuner is loaded that is actually valid for the radio mode. Subdev ops should only return errors when there is a real problem (e.g. i2c errors) and should just return 0 if a request is not for them. That's why I posted these first two patches: these functions suggest that you can return an error if the mode doesn't match when you really cannot. If I call v4l2_device_call_until_err() for e.g. s_frequency, then the error that is returned should match a real error (e.g. an i2c error), not that one of the tv tuners refused the radio mode. I know there is a radio tuner somewhere, otherwise there wouldn't be a /dev/radio node. I firmly believe that the RFCv4 series is correct and just needs an additional patch adding some documentation. That said, it would make sense to move the first three patches to the end instead if you prefer. Since these are cleanups, not bug fixes like the others. The errors at tuner should be propagated. If there's just one tuner, the error code should just be returned by the ioctl. But, if there are two tuners, if the bridge driver calls G_TUNER (or any other tuner subdev call) and both tuners return -EINVAL, then it needs to return -EINVAL to userspace. If just one returns -EINVAL, and the other tuner returns 0, then it should return 0. So, it is about the opposite behaviour implemented at v4l2_device_call_until_err(). Sorry, but no, that's not true. You are trying to use the error codes from tuner subdevs to determine whether none of the tuner subdevs support a certain tuner mode. Not only that. There are some cases where the tuner driver may not bind for some reason. So, even if the bridge driver does support a certain mode, a call to G_TUNER may fail (for example, if tea5767 probe failed). Only with a proper return code, the bridge driver can detect if the driver found some issue. Surely, that's an error reported by tuner_probe, isn't it? That's supposed to ensure that the tuner driver was loaded and initialized correctly. I'm not sure if it does, but that's definitely where any errors of that kind should be reported. Looking at it some more, it seems to me that s_type_addr should also return an error if there are problems. Ditto for tuner_s_config. An alternative solution is to keep a 'initialized' boolean that is set to true once the tuner is fully configured. If g_tuner et al are called when the tuner is not fully configured, then you can return -ENODEV or -EIO or something like that. But that's a separate status check and has nothing to do with mode checking. E.g., you want to change something for a radio tuner and there are no radio tuner subdevs. But that's the job of the bridge driver to check. That has the overview, the lowly subdevs do not. The subdevs just filter the ops and check the mode to see if they should handle it and ignore it otherwise. Only if they have to handle it will they return a possible error. The big problem with trying to use subdev errors codes for this is that you don't see the difference between a real error of a subdev (e.g. -EIO when an i2c access fails) and a subdev that returns -EINVAL just because it didn't understand the tuner mode. So the bridge may return -EINVAL to the application instead of the real error, which is -EIO. An -EIO would also be discarded, as errors at v4l2_device_call_all() calls don't return anything. So, currently, the bridge has to assume that no errors happened and return 0. Obviously,
Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.
On 8 June 2011 18:24, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That works much better, thank you. -- Regards, Laurent Pinchart So, how is it going? Are you finally accepting the patches for mainline? Thank you, -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
Am 10.06.2011 um 22:50 schrieb Greg KH g...@kroah.com: On Fri, Jun 10, 2011 at 12:48:15PM -0700, Sarah Sharp wrote: On Thu, Jun 09, 2011 at 08:18:05PM -0700, Greg KH wrote: On Thu, Jun 09, 2011 at 05:21:03PM -0700, Sarah Sharp wrote: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Do people really want to virtualize the whole xHCI controller, or just specific ports or devices to the guest operating system? A host OS could chose to virtualize the whole xHCI controller if it wanted to. That's part of the reason why xHCI does all the bandwidth checking in hardware, not in software. And here I thought it did that so it would be correct :) If just specific ports, would something like usbip be better for virtual machines, with the USB traffic going over the network connection between the guest/host? It could be done that way too. But that doesn't help if you're trying to run Windows under Linux, right? Only if all the guest OSes use the same USB IP protocol then it would work. usbip works on Windows as well as Linux. Do you have a reliable, working usbip solution at hand that work on Windows and Linux and doesn't require real network access, which can be a no-go for some scenarios? But how could you run Windows with a xHCI controller in a guest, as Windows has no xHCI driver? What would it expect to see? There are drivers for xhci adapters on Windows. Also, this whole discussion is pretty much future oriented - which most likely means built-in xhci drivers anywhere. No, in all seriousity, the main reason to go for FV vs PV is that so far, the best tested and working drivers are built for real hardware. I'm still unsatisfied with the PV driver situation for virtio on Windows. It's just incredibly hard to get Windows drivers right - and open source developers sure are not good at it :) But sure, let's talk about it during LinuxCon as well - there's a good chance you know more there than me :) Alex -- 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: Crash on unplug with the uvc driver in linuxtv/staging/for_v3.1
On Monday, June 13, 2011 11:41:42 Laurent Pinchart wrote: Hi Hans (and Hans), On Saturday 11 June 2011 11:16:10 Laurent Pinchart wrote: On Thursday 09 June 2011 13:22:03 Hans de Goede wrote: Hi, When I unplug a uvc camera *while streaming* I get: [15824.809741] BUG: unable to handle kernel NULL pointer dereference at (null) [snip] I've not tested if this also impacts 3.0!! It probably does. Thanks for the report. I'll fix it. It does. Fixing the problem turns to be more complex than expected. The crash is caused by media entities life time management issues. Entities associated with video device nodes are unregistered in video_unregister_device(). This removes the entity from its parent's entities list, and sets the entity's parent to NULL. Entities also get/put references to their parent's module through media_entity_get() and media_entity_put(). Those functions are called in the open and release handlers of video device nodes and subdev device nodes. The reason behind this is to avoid a parent module from being removed while a subdev is opened, as closing a subdev can call to the parent's module through board code. When a UVC device is unplugged while streaming, the uvcvideo driver will call video_unregister_device() in the disconnect handler. This will in turn call media_device_unregister_entity() which sets the entity's parent to NULL. When the user then closes open video device nodes, v4l2_release() calls media_entity_put() which tries to dereference entity-parent, and oopses. I've tried to move the media_device_unregister_entity() call from video_unregister_device() to v4l2_device_release() (called when the last reference to the video device is released). media_entity_put() is then called before the entity is unregistered, but that results in a different oops: as this happens after the USB disconnect callback is called, entity-parent-dev- driver is now NULL, and trying to access entity-parent-dev-driver-owner to decrement the module use count oopses. One possible workaround is to remove media_entity_get()/media_entity_put() calls from v4l2-dev.c. As the original purpose of those functions was to avoid a parent module from being removed while still accessible through board code, and all existing MC-enabled drivers register video device nodes with the owner equal to the entity's parent's module, we can safely do it. I'd rather implement a proper solution though, but that's not straightforward. We short-circuit the kernel reference management by going through board code. There's something fundamentally wrong in the way we manage subdevs and device/module reference counts. I'm not sure where the proper fix should go to though. Hmm. Tricky. media_device_unregister_entity() is definitely called in the wrong place. It should move to v4l2_device_release(). I wonder why media_entity_get/put are called in v4l2_open and v4l2_release. That should be in __video_register_device and v4l2_device_release as far as I can see. Just closing a device node shouldn't be cause for changing the module's refcount, that device node registration and the release after unregistration. I also wonder whether instead of refcounting the module in media_entity_get/put you should refcount the device (entity-parent-dev). I have to admit that I don't quite understand why the USB disconnect zeroes entity-parent-dev-driver. I hope this gives some ideas... 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: [RFCv4 PATCH 1/8] tuner-core: rename check_mode to supported_mode
Em 13-06-2011 07:23, Hans Verkuil escreveu: On Monday, June 13, 2011 00:06:19 Mauro Carvalho Chehab wrote: Em 12-06-2011 15:09, Hans Verkuil escreveu: On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote: Em 12-06-2011 13:07, Hans Verkuil escreveu: On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote: Em 12-06-2011 07:59, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com The check_mode function checks whether a mode is supported. So calling it supported_mode is more appropriate. In addition it returned either 0 or -EINVAL which suggests that the -EINVAL error should be passed on. However, that's not the case so change the return type to bool. I prefer to keep returning -EINVAL. This is the proper thing to do, and to return the result to the caller. A fixme should be added though, so, after someone add a subdev call that would properly handle the -EINVAL code for multiple tuners, the functions should return the error code instead of 0. No, you can't return -EINVAL here. It is the responsibility of the bridge driver to determine whether there is e.g. a radio tuner. So if one of these tuner subdevs is called with mode radio while it is a tv tuner, then that is not an error, but instead it is a request that can safely be ignored as not relevant for that tuner. It is up to the bridge driver to ensure that a tuner is loaded that is actually valid for the radio mode. Subdev ops should only return errors when there is a real problem (e.g. i2c errors) and should just return 0 if a request is not for them. That's why I posted these first two patches: these functions suggest that you can return an error if the mode doesn't match when you really cannot. If I call v4l2_device_call_until_err() for e.g. s_frequency, then the error that is returned should match a real error (e.g. an i2c error), not that one of the tv tuners refused the radio mode. I know there is a radio tuner somewhere, otherwise there wouldn't be a /dev/radio node. I firmly believe that the RFCv4 series is correct and just needs an additional patch adding some documentation. That said, it would make sense to move the first three patches to the end instead if you prefer. Since these are cleanups, not bug fixes like the others. The errors at tuner should be propagated. If there's just one tuner, the error code should just be returned by the ioctl. But, if there are two tuners, if the bridge driver calls G_TUNER (or any other tuner subdev call) and both tuners return -EINVAL, then it needs to return -EINVAL to userspace. If just one returns -EINVAL, and the other tuner returns 0, then it should return 0. So, it is about the opposite behaviour implemented at v4l2_device_call_until_err(). Sorry, but no, that's not true. You are trying to use the error codes from tuner subdevs to determine whether none of the tuner subdevs support a certain tuner mode. Not only that. There are some cases where the tuner driver may not bind for some reason. So, even if the bridge driver does support a certain mode, a call to G_TUNER may fail (for example, if tea5767 probe failed). Only with a proper return code, the bridge driver can detect if the driver found some issue. Surely, that's an error reported by tuner_probe, isn't it? That's supposed to ensure that the tuner driver was loaded and initialized correctly. I'm not sure if it does, but that's definitely where any errors of that kind should be reported. Looking at it some more, it seems to me that s_type_addr should also return an error if there are problems. Ditto for tuner_s_config. An alternative solution is to keep a 'initialized' boolean that is set to true once the tuner is fully configured. If g_tuner et al are called when the tuner is not fully configured, then you can return -ENODEV or -EIO or something like that. NACK. This would be just an ugly workaround. But that's a separate status check and has nothing to do with mode checking. E.g., you want to change something for a radio tuner and there are no radio tuner subdevs. But that's the job of the bridge driver to check. That has the overview, the lowly subdevs do not. The subdevs just filter the ops and check the mode to see if they should handle it and ignore it otherwise. Only if they have to handle it will they return a possible error. The big problem with trying to use subdev errors codes for this is that you don't see the difference between a real error of a subdev (e.g. -EIO when an i2c access fails) and a subdev that returns -EINVAL just because it didn't understand the tuner mode. So the bridge may return -EINVAL to the application instead of the real error, which is -EIO. An -EIO would also be discarded, as errors at v4l2_device_call_all() calls don't return anything. So, currently, the bridge has to assume that no errors happened and return 0. Obviously,
Re: [RFCv4 PATCH 1/8] tuner-core: rename check_mode to supported_mode
On Monday, June 13, 2011 13:45:14 Mauro Carvalho Chehab wrote: Em 13-06-2011 07:23, Hans Verkuil escreveu: On Monday, June 13, 2011 00:06:19 Mauro Carvalho Chehab wrote: Em 12-06-2011 15:09, Hans Verkuil escreveu: On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote: Em 12-06-2011 13:07, Hans Verkuil escreveu: On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote: Em 12-06-2011 07:59, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com The check_mode function checks whether a mode is supported. So calling it supported_mode is more appropriate. In addition it returned either 0 or -EINVAL which suggests that the -EINVAL error should be passed on. However, that's not the case so change the return type to bool. I prefer to keep returning -EINVAL. This is the proper thing to do, and to return the result to the caller. A fixme should be added though, so, after someone add a subdev call that would properly handle the -EINVAL code for multiple tuners, the functions should return the error code instead of 0. No, you can't return -EINVAL here. It is the responsibility of the bridge driver to determine whether there is e.g. a radio tuner. So if one of these tuner subdevs is called with mode radio while it is a tv tuner, then that is not an error, but instead it is a request that can safely be ignored as not relevant for that tuner. It is up to the bridge driver to ensure that a tuner is loaded that is actually valid for the radio mode. Subdev ops should only return errors when there is a real problem (e.g. i2c errors) and should just return 0 if a request is not for them. That's why I posted these first two patches: these functions suggest that you can return an error if the mode doesn't match when you really cannot. If I call v4l2_device_call_until_err() for e.g. s_frequency, then the error that is returned should match a real error (e.g. an i2c error), not that one of the tv tuners refused the radio mode. I know there is a radio tuner somewhere, otherwise there wouldn't be a /dev/radio node. I firmly believe that the RFCv4 series is correct and just needs an additional patch adding some documentation. That said, it would make sense to move the first three patches to the end instead if you prefer. Since these are cleanups, not bug fixes like the others. The errors at tuner should be propagated. If there's just one tuner, the error code should just be returned by the ioctl. But, if there are two tuners, if the bridge driver calls G_TUNER (or any other tuner subdev call) and both tuners return -EINVAL, then it needs to return -EINVAL to userspace. If just one returns -EINVAL, and the other tuner returns 0, then it should return 0. So, it is about the opposite behaviour implemented at v4l2_device_call_until_err(). Sorry, but no, that's not true. You are trying to use the error codes from tuner subdevs to determine whether none of the tuner subdevs support a certain tuner mode. Not only that. There are some cases where the tuner driver may not bind for some reason. So, even if the bridge driver does support a certain mode, a call to G_TUNER may fail (for example, if tea5767 probe failed). Only with a proper return code, the bridge driver can detect if the driver found some issue. Surely, that's an error reported by tuner_probe, isn't it? That's supposed to ensure that the tuner driver was loaded and initialized correctly. I'm not sure if it does, but that's definitely where any errors of that kind should be reported. Looking at it some more, it seems to me that s_type_addr should also return an error if there are problems. Ditto for tuner_s_config. An alternative solution is to keep a 'initialized' boolean that is set to true once the tuner is fully configured. If g_tuner et al are called when the tuner is not fully configured, then you can return -ENODEV or -EIO or something like that. NACK. This would be just an ugly workaround. Agreed :-) But that's a separate status check and has nothing to do with mode checking. E.g., you want to change something for a radio tuner and there are no radio tuner subdevs. But that's the job of the bridge driver to check. That has the overview, the lowly subdevs do not. The subdevs just filter the ops and check the mode to see if they should handle it and ignore it otherwise. Only if they have to handle it will they return a possible error. The big problem with trying to use subdev errors codes for this is that you don't see the difference between a real error of a subdev (e.g. -EIO when an i2c access fails) and a subdev that returns -EINVAL just because it didn't understand the tuner mode. So the bridge may return -EINVAL to the application instead of the real error,
Re: [RFCv4 PATCH 1/8] tuner-core: rename check_mode to supported_mode
Em 13-06-2011 09:07, Hans Verkuil escreveu: On Monday, June 13, 2011 13:45:14 Mauro Carvalho Chehab wrote: Em 13-06-2011 07:23, Hans Verkuil escreveu: On Monday, June 13, 2011 00:06:19 Mauro Carvalho Chehab wrote: Em 12-06-2011 15:09, Hans Verkuil escreveu: On Sunday, June 12, 2011 19:27:21 Mauro Carvalho Chehab wrote: Em 12-06-2011 13:07, Hans Verkuil escreveu: On Sunday, June 12, 2011 16:37:55 Mauro Carvalho Chehab wrote: Em 12-06-2011 07:59, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com The check_mode function checks whether a mode is supported. So calling it supported_mode is more appropriate. In addition it returned either 0 or -EINVAL which suggests that the -EINVAL error should be passed on. However, that's not the case so change the return type to bool. I prefer to keep returning -EINVAL. This is the proper thing to do, and to return the result to the caller. A fixme should be added though, so, after someone add a subdev call that would properly handle the -EINVAL code for multiple tuners, the functions should return the error code instead of 0. No, you can't return -EINVAL here. It is the responsibility of the bridge driver to determine whether there is e.g. a radio tuner. So if one of these tuner subdevs is called with mode radio while it is a tv tuner, then that is not an error, but instead it is a request that can safely be ignored as not relevant for that tuner. It is up to the bridge driver to ensure that a tuner is loaded that is actually valid for the radio mode. Subdev ops should only return errors when there is a real problem (e.g. i2c errors) and should just return 0 if a request is not for them. That's why I posted these first two patches: these functions suggest that you can return an error if the mode doesn't match when you really cannot. If I call v4l2_device_call_until_err() for e.g. s_frequency, then the error that is returned should match a real error (e.g. an i2c error), not that one of the tv tuners refused the radio mode. I know there is a radio tuner somewhere, otherwise there wouldn't be a /dev/radio node. I firmly believe that the RFCv4 series is correct and just needs an additional patch adding some documentation. That said, it would make sense to move the first three patches to the end instead if you prefer. Since these are cleanups, not bug fixes like the others. The errors at tuner should be propagated. If there's just one tuner, the error code should just be returned by the ioctl. But, if there are two tuners, if the bridge driver calls G_TUNER (or any other tuner subdev call) and both tuners return -EINVAL, then it needs to return -EINVAL to userspace. If just one returns -EINVAL, and the other tuner returns 0, then it should return 0. So, it is about the opposite behaviour implemented at v4l2_device_call_until_err(). Sorry, but no, that's not true. You are trying to use the error codes from tuner subdevs to determine whether none of the tuner subdevs support a certain tuner mode. Not only that. There are some cases where the tuner driver may not bind for some reason. So, even if the bridge driver does support a certain mode, a call to G_TUNER may fail (for example, if tea5767 probe failed). Only with a proper return code, the bridge driver can detect if the driver found some issue. Surely, that's an error reported by tuner_probe, isn't it? That's supposed to ensure that the tuner driver was loaded and initialized correctly. I'm not sure if it does, but that's definitely where any errors of that kind should be reported. Looking at it some more, it seems to me that s_type_addr should also return an error if there are problems. Ditto for tuner_s_config. An alternative solution is to keep a 'initialized' boolean that is set to true once the tuner is fully configured. If g_tuner et al are called when the tuner is not fully configured, then you can return -ENODEV or -EIO or something like that. NACK. This would be just an ugly workaround. Agreed :-) But that's a separate status check and has nothing to do with mode checking. E.g., you want to change something for a radio tuner and there are no radio tuner subdevs. But that's the job of the bridge driver to check. That has the overview, the lowly subdevs do not. The subdevs just filter the ops and check the mode to see if they should handle it and ignore it otherwise. Only if they have to handle it will they return a possible error. The big problem with trying to use subdev errors codes for this is that you don't see the difference between a real error of a subdev (e.g. -EIO when an i2c access fails) and a subdev that returns -EINVAL just because it didn't understand the tuner mode. So the bridge may return -EINVAL to the application instead of the real error, which is -EIO. An -EIO would also be discarded, as errors at
[RFCv5 PATCH 0/9] tuner-core: fix g_freq/s_std and g/s_tuner
Changes from RFCv4: - Removed the controversial first two patches that changed/renamed check_mode and set_mode_freq. - Added documentation to tuner-core.c and v4l2-subdev.h - Added feature-removal-schedule entries. - Added a small patch to remove the now unused tuner s_mode op in v4l2-subdev.h. The first five patches are the actual bug fixes and should also go into v3.0. The feature-removal-schedule patch should also go into v3.0 to give people an early heads-up (not that anyone ever reads that stuff...) 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
[RFCv5 PATCH 1/9] tuner-core: fix s_std and s_tuner.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in
s_std/s_tuner
first calls set_mode, and if that returns 0 (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 62 -
1 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 5748d04..b634bab 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -742,19 +742,15 @@ static inline int check_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns -EINVAL, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
+ * Otherwise, changes the mode and returns 0.
*/
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
+static int set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -770,17 +766,27 @@ static int set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return 0;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq: frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return 0;
}
/*
@@ -1076,10 +1082,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_RADIO, 0) == -EINVAL)
- return 0;
+ if (set_mode(t, V4L2_TUNER_RADIO) == 0)
+ set_freq(t, 0);
return 0;
}
@@ -,25 +1116,22 @@ static int tuner_s_power(struct v4l2_subdev *sd, int on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0) == -EINVAL)
+ if (set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = std;
tuner_fixup_std(t);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
-
- if (set_mode_freq(client, t, f-type, f-frequency) == -EINVAL)
- return 0;
+ if (set_mode(t, f-type) == 0)
+ set_freq(t, f-frequency);
return 0;
}
@@ -1198,13 +1200,14 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, vt-type, 0) == -EINVAL)
+ if (set_mode(t, vt-type))
return 0;
- if (t-mode == V4L2_TUNER_RADIO)
+ if (t-mode == V4L2_TUNER_RADIO) {
t-audmode = vt-audmode;
+ set_freq(t, 0);
+ }
return 0;
}
@@ -1239,7 +1242,8 @@ static int
[RFCv5 PATCH 2/9] tuner-core: fix tuner_resume: use t-mode instead of t-type.
From: Hans Verkuil hans.verk...@cisco.com set_mode is called with t-type, which is the tuner type. Instead, use t-mode which is the actual tuner mode (i.e. radio vs tv). Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/tuner-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index b634bab..3b30d80 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1242,7 +1242,7 @@ static int tuner_resume(struct i2c_client *c) tuner_dbg(resume\n); if (!t-standby) - if (set_mode(t, t-type) == 0) + if (set_mode(t, t-mode) == 0) set_freq(t, 0); return 0; -- 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
[RFCv5 PATCH 3/9] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner.
From: Hans Verkuil hans.verk...@cisco.com The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not. The spec does not require applications to fill in the type, and if they leave it at 0 then the 'supported_mode' call in tuner-core.c will return false and the ioctl does nothing. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/v4l2-ioctl.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 213ba7d..26bf3bf 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -1822,6 +1822,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_g_tuner) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; ret = ops-vidioc_g_tuner(file, fh, p); if (!ret) dbgarg(cmd, index=%d, name=%s, type=%d, @@ -1840,6 +1842,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_s_tuner) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; dbgarg(cmd, index=%d, name=%s, type=%d, capability=0x%x, rangelow=%d, rangehigh=%d, signal=%d, afc=%d, @@ -1858,6 +1862,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_g_frequency) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; ret = ops-vidioc_g_frequency(file, fh, p); if (!ret) dbgarg(cmd, tuner=%d, type=%d, frequency=%d\n, -- 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
[RFCv5 PATCH 8/9] feature-removal-schedule: change in how radio device nodes are handled.
From: Hans Verkuil hans.verk...@cisco.com Radio devices have weird side-effects when used with combined TV/radio tuners and the V4L2 spec is ambiguous on how it should work. This results in inconsistent driver behavior which makes life hard for everyone. Be more strict in when and how the switch between radio and tv mode takes place and make sure all drivers behave the same. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/feature-removal-schedule.txt | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1a9446b..9df0e09 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -600,3 +600,25 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. Who: Laurent Pinchart laurent.pinch...@ideasonboard.com + +What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. + If not, return -EINVAL. +When: 3.2 +Why: It makes no sense to switch the tuner to radio mode by calling + VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by + calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a + move to more consistent handling of tv and radio tuners. +Who: Hans Verkuil hans.verk...@cisco.com + + + +What: Opening a radio device node will no longer automatically switch the + tuner mode from tv to radio. +When: 3.3 +Why: Just opening a V4L device should not change the state of the hardware + like that. It's very unexpected and against the V4L spec. Instead, you + switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second + and last step of the move to consistent handling of tv and radio tuners. +Who: Hans Verkuil hans.verk...@cisco.com + + -- 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
[RFCv5 PATCH 4/9] pvrusb2: fix g/s_tuner support.
From: Hans Verkuil hans.verk...@cisco.com
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.
Tested with my pvrusb2.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 9d0dd08..e98d382 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -3046,6 +3046,8 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
if (hdw-input_dirty || hdw-audiomode_dirty || hdw-force_dirty) {
struct v4l2_tuner vt;
memset(vt, 0, sizeof(vt));
+ vt.type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
vt.audmode = hdw-audiomode_val;
v4l2_device_call_all(hdw-v4l2_dev, 0, tuner, s_tuner, vt);
}
@@ -5171,6 +5173,8 @@ void pvr2_hdw_status_poll(struct pvr2_hdw *hdw)
{
struct v4l2_tuner *vtp = hdw-tuner_signal_info;
memset(vtp, 0, sizeof(*vtp));
+ vtp-type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
hdw-tuner_signal_stale = 0;
/* Note: There apparently is no replacement for VIDIOC_CROPCAP
using v4l2-subdev - therefore we can't support that AT ALL right
--
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
[RFCv5 PATCH 7/9] tuner-core/v4l2-subdev: document that the type field has to be filled in.
From: Hans Verkuil hans.verk...@cisco.com
The tuner ops g_frequency, g_tuner and s_tuner require that the tuner type
field is filled in. Document this.
The tuner-core doc is based on a patch from Mauro Carvalho Chehab
mche...@redhat.com.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 29 +
include/media/v4l2-subdev.h |7 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 3b30d80..cb007d3 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1135,6 +1135,16 @@ static int tuner_s_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
return 0;
}
+/**
+ * tuner_g_frequency - Get the tuned frequency for the tuner
+ * @sd: pointer to struct v4l2_subdev
+ * @f: pointer to struct v4l2_frequency
+ *
+ * At return, the structure f will be filled with tuner frequency
+ * if the tuner matches the f-type.
+ * Note: f-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_g_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
@@ -1157,6 +1167,16 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
return 0;
}
+/**
+ * tuner_g_tuner - Fill in tuner information
+ * @sd: pointer to struct v4l2_subdev
+ * @vt: pointer to struct v4l2_tuner
+ *
+ * At return, the structure vt will be filled with tuner information
+ * if the tuner matches vt-type.
+ * Note: vt-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
@@ -1197,6 +1217,15 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
return 0;
}
+/**
+ * tuner_s_tuner - Set the tuner's audio mode
+ * @sd: pointer to struct v4l2_subdev
+ * @vt: pointer to struct v4l2_tuner
+ *
+ * Sets the audio mode if the tuner matches vt-type.
+ * Note: vt-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 2245020..2884e3e 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -175,6 +175,13 @@ struct v4l2_subdev_core_ops {
/* s_radio: v4l device was opened in radio mode.
+ g_frequency: freq-type must be filled in. Normally done by video_ioctl2
+ or the bridge driver.
+
+ g_tuner:
+ s_tuner: vt-type must be filled in. Normally done by video_ioctl2 or the
+ bridge driver.
+
s_type_addr: sets tuner type and its I2C addr.
s_config: sets tda9887 specific stuff, like port1, port2 and qss
--
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
[RFCv5 PATCH 9/9] tuner-core: simplify the standard fixup.
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 93 +++--
1 files changed, 28 insertions(+), 65 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index cb007d3..89d0e4e 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -841,7 +841,8 @@ static void set_tv_freq(struct i2c_client *c, unsigned int
freq)
/**
* tuner_fixup_std - force a given video standard variant
*
- * @t: tuner internal struct
+ * @t: tuner internal struct
+ * @std: TV standard
*
* A few devices or drivers have problem to detect some standard variations.
* On other operational systems, the drivers generally have a per-country
@@ -851,57 +852,39 @@ static void set_tv_freq(struct i2c_client *c, unsigned
int freq)
* to distinguish all video standard variations, a modprobe parameter can
* be used to force a video standard match.
*/
-static int tuner_fixup_std(struct tuner *t)
+static v4l2_std_id tuner_fixup_std(struct tuner *t, v4l2_std_id std)
{
- if ((t-std V4L2_STD_PAL) == V4L2_STD_PAL) {
+ if (pal[0] != '-' (std V4L2_STD_PAL) == V4L2_STD_PAL) {
switch (pal[0]) {
case '6':
- tuner_dbg(insmod fixup: PAL = PAL-60\n);
- t-std = V4L2_STD_PAL_60;
- break;
+ return V4L2_STD_PAL_60;
case 'b':
case 'B':
case 'g':
case 'G':
- tuner_dbg(insmod fixup: PAL = PAL-BG\n);
- t-std = V4L2_STD_PAL_BG;
- break;
+ return V4L2_STD_PAL_BG;
case 'i':
case 'I':
- tuner_dbg(insmod fixup: PAL = PAL-I\n);
- t-std = V4L2_STD_PAL_I;
- break;
+ return V4L2_STD_PAL_I;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: PAL = PAL-DK\n);
- t-std = V4L2_STD_PAL_DK;
- break;
+ return V4L2_STD_PAL_DK;
case 'M':
case 'm':
- tuner_dbg(insmod fixup: PAL = PAL-M\n);
- t-std = V4L2_STD_PAL_M;
- break;
+ return V4L2_STD_PAL_M;
case 'N':
case 'n':
- if (pal[1] == 'c' || pal[1] == 'C') {
- tuner_dbg(insmod fixup: PAL = PAL-Nc\n);
- t-std = V4L2_STD_PAL_Nc;
- } else {
- tuner_dbg(insmod fixup: PAL = PAL-N\n);
- t-std = V4L2_STD_PAL_N;
- }
- break;
- case '-':
- /* default parameter, do nothing */
- break;
+ if (pal[1] == 'c' || pal[1] == 'C')
+ return V4L2_STD_PAL_Nc;
+ return V4L2_STD_PAL_N;
default:
tuner_warn(pal= argument not recognised\n);
break;
}
}
- if ((t-std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
+ if (secam[0] != '-' (std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
switch (secam[0]) {
case 'b':
case 'B':
@@ -909,63 +892,42 @@ static int tuner_fixup_std(struct tuner *t)
case 'G':
case 'h':
case 'H':
- tuner_dbg(insmod fixup: SECAM = SECAM-BGH\n);
- t-std = V4L2_STD_SECAM_B |
-V4L2_STD_SECAM_G |
-V4L2_STD_SECAM_H;
- break;
+ return V4L2_STD_SECAM_B |
+ V4L2_STD_SECAM_G |
+ V4L2_STD_SECAM_H;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: SECAM = SECAM-DK\n);
- t-std = V4L2_STD_SECAM_DK;
- break;
+ return V4L2_STD_SECAM_DK;
case 'l':
case 'L':
- if ((secam[1] == 'C') || (secam[1] == 'c')) {
- tuner_dbg(insmod fixup: SECAM = SECAM-L'\n);
- t-std = V4L2_STD_SECAM_LC;
- } else {
- tuner_dbg(insmod
[RFCv5 PATCH 6/9] v4l2-subdev.h: remove unused s_mode tuner op.
From: Hans Verkuil hans.verk...@cisco.com
s_mode is no longer used, so remove it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/media/v4l2-subdev.h |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1562c4f..2245020 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -173,16 +173,13 @@ struct v4l2_subdev_core_ops {
struct v4l2_event_subscription *sub);
};
-/* s_mode: switch the tuner to a specific tuner mode. Replacement of s_radio.
-
- s_radio: v4l device was opened in Radio mode, to be replaced by s_mode.
+/* s_radio: v4l device was opened in radio mode.
s_type_addr: sets tuner type and its I2C addr.
s_config: sets tda9887 specific stuff, like port1, port2 and qss
*/
struct v4l2_subdev_tuner_ops {
- int (*s_mode)(struct v4l2_subdev *sd, enum v4l2_tuner_type);
int (*s_radio)(struct v4l2_subdev *sd);
int (*s_frequency)(struct v4l2_subdev *sd, struct v4l2_frequency *freq);
int (*g_frequency)(struct v4l2_subdev *sd, struct v4l2_frequency *freq);
--
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
[RFCv5 PATCH 5/9] bttv: fix s_tuner for radio.
From: Hans Verkuil hans.verk...@cisco.com Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/bt8xx/bttv-driver.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index a97cf27..834a483 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -3474,7 +3474,7 @@ static int radio_s_tuner(struct file *file, void *priv, if (0 != t-index) return -EINVAL; - bttv_call_all(btv, tuner, g_tuner, t); + bttv_call_all(btv, tuner, s_tuner, t); return 0; } -- 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: Improving kernel - userspace (usbfs) usb device hand off
Em 13-06-2011 06:05, Felipe Balbi escreveu: Hi, On Fri, Jun 10, 2011 at 05:43:06PM -0500, Theodore Kilgore wrote: there's nothing in the USB spec that says you need different product IDs for different modes of operation. No matter if it's still or webcam configuration, the underlying function is the same: capture images using a set of lenses and image sensor. True, true. But I will add that most of these cameras are Class 255, Subclass 255, Protocol 255 (Proprietary, Proprietary, Proprietary). well, if the manufacturer doesn't want to implement UVC for whatever reason, it's his call ;-) This argument is bogus. UVC were implemented too late. There are lots of chipsets that are not UVC-compliant, simply because there were no UVC at the time those chipsets were designed. Still today, newer devices using those chipsets are still at the market. This is the same as saying that we should not support USB 1.1 or USB 2.0 because they're not fully USB 3.0 compliant. 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
Request for driver for new video capture card
Hello, My name is Alex Tucker and I am the engineering manager here at ViewCast. We have released two new Osprey cards based on the Conexant CX23888 chipset - which is similar to the CX25878/BT878A chipset that has some support in the Open Source community. We are interested in having Linux driver support for the new cards. I found the www.linuxdriverproject.org website where the process for having Linux drivers created (at http://www.linuxdriverproject.org/foswiki/bin/view/Main/CompanyProcess ) can be found. We can provide some specifications, the card hardware itself, and some support for this endeavor.Please contact me directly if interested. Thanks very much! Alex Tucker Engineering Manager atuc...@viewcast.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 1/2] V4L: mt9m111: propagate higher level abstraction down in functions
On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote: A general question to you: from your comments I haven't understood: have you also tested the patches or only reviewed them? I had reviewed them so far. Now, please have my : Acked-by: Robert Jarzmik robert.jarz...@free.fr The ack includes a test done on my platform, with a suspend in the middle of an image capture. The system wakes up and sends back the captured image without a problem. The test is for your 2 patch series : mt9m111: propagate higher level abstraction down in functions and v2 of pxa-camera: minor updates. Cheers. -- Robert -- 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/2] V4L: mt9m111: propagate higher level abstraction down in functions
On Mon, 13 Jun 2011, Robert Jarzmik wrote: On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote: A general question to you: from your comments I haven't understood: have you also tested the patches or only reviewed them? I had reviewed them so far. Now, please have my : Acked-by: Robert Jarzmik robert.jarz...@free.fr Great, thanks a lot! The ack includes a test done on my platform, with a suspend in the middle of an image capture. The system wakes up and sends back the captured image without a problem. The test is for your 2 patch series : mt9m111: propagate higher level abstraction down in functions and v2 of pxa-camera: minor updates. Cheers. -- Robert Regards Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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:Mon Jun 13 19:01:20 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: ERRORS 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: ERRORS 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Bart Coninckx Sent: lundi 13 juin 2011 19:14 To: linux-media@vger.kernel.org Subject: Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200 On 06/13/11 00:30, Bart Coninckx wrote: Hi all, hope you can help me this one, because there's not a whole of info about similar problems to be found. I have a Technotrend S2-3200 with CI and on three different distros I get this dvb_ca adaptor 0: PC card did not respond :( in /var/log/messages. I guess this is the reason why I cannot see encrypted channels on Linux. Unencrypted works fine. In Windows XP the cord works fine too. I tried Opensuse 11.4, the latest Mythbuntu and the latest Mythdora. Can anyone give any hints on how to go about this? Your reporting isn't very clear: - When you try under Linux and Windows, is-it the same PC with the same configuration? - Does-it work with unscrambled channels on Windows ? - Can you decrypt scrambled channels on Windows ? - Does-it work with unscrambled channels on Linux ? - Can you decrypt scrambled channels on Linux ? thx!!! Bart -- 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 All, (risking to just talk to myself, but hey, that would not be the first time). I manually reinstalled the latest linuxtv media drivers, but this this does not seem to bring any relieve. Any ideas much appreciated! B. -- 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
Latest media-tree results in system hang, an no IR.
With the latest media-tree, any access to my TV card (using tvtime and mplayer to watch through composite) results in my Arch Linux (2.6.39) system freezing. Here is the relavent part of my dmesg upon the freeze: http://codepad.org/q5MxDqAI I compiled the latest media-tree in order to, finally, get my infrared receiver working, however it still does not. An entry is made in /proc/bus/input/devices which points to /dev/input/event5; however. the /dev/lirc device node is not present, and using irw does not seem to recognise any input. Is anyone else experiencing such issues, and has anyone managed to get IR actually working on the HVR-1120. Thanks. -- 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
Status on DRX-K based tuner cards
Hello there, I just wanted to ask whether there is a change in the situation of tuners used in e.g. Terratec H5 / WinTV HVR-930c / MSI Digivox Trio etc. As far as I can understand all the information available in various mailing lists and boards, the real problem was (or is) the DRX-K chip. Now there's a driver for Terratec H7 which includes some drxk-* source code. Is this a different chip or is this the desired source code for providing linux support for those devices? I would really appreciate linux support for this kind of tuners - of course I've got one myself, but in general I hate the idea that there are products not available to the linux domain. Especially when it comes to TV - there are all kinds of custom VDR solutions featuring Linux, as well as many lightweight laptops like the eeePC, which can't access the huge variety of dvb tuner cards. Best Regards Markus P. -- 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: Status on DRX-K based tuner cards
On Mon, Jun 13, 2011 at 6:05 PM, Markus Partheymueller m...@klee-parthy.de wrote: Hello there, I just wanted to ask whether there is a change in the situation of tuners used in e.g. Terratec H5 / WinTV HVR-930c / MSI Digivox Trio etc. As far as I can understand all the information available in various mailing lists and boards, the real problem was (or is) the DRX-K chip. Now there's a driver for Terratec H7 which includes some drxk-* source code. Is this a different chip or is this the desired source code for providing linux support for those devices? I would really appreciate linux support for this kind of tuners - of course I've got one myself, but in general I hate the idea that there are products not available to the linux domain. Especially when it comes to TV - there are all kinds of custom VDR solutions featuring Linux, as well as many lightweight laptops like the eeePC, which can't access the huge variety of dvb tuner cards. In the case of the drx-k, the problem is no longer with the chipset vendor - they have provided source code under a license that will permit merging into an upstream kernel. The problem at this point is simply a lack of developers who are both qualified and willing to do the work. A secondary problem is that even if somebody gets a board working, a huge refactoring of the code is required in order for it to be accepted upstream. This for example is why the drx-j (the ATSC/QAM equivalent to the drxk-) isn't in the mainline kernel despite there having been an out-of-tree GPL driver available for almost a year. 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
Some fixes for alsa_stream
Hi Devin, I've made a few fixes for your alsa_stream.c, used on tvtime. They are at: http://git.linuxtv.org/xawtv3.git In particular, those are the more interesting ones: commit a1bb5ade5c2b09d6d6d624d18025f9e2c4398495 alsa_stream: negotiate the frame rate Without this patch, one of my em28xx devices doesn't work. It uses 32 k rate, while the playback minimal rate is 44.1 k. I've changed the entire frame rate logic, to be more reliable, and to avoid needing to do frame rate conversion, if both capture and playback devices support the same rate. commit 8adb3d7442b22022b9ca897b0b914962adf41270 alsa_stream: Reduce CPU usage by putting the thread into blocking mode This is just an optimization. I can't see why are you using a non-block mode, as it works fine blocking. commit c67f7aeb86c1caceb7ab30439d169356ea5b1e72 alsa_stream.c: use mmap mode instead of the normal mode Instead of using the normal way, this patch implements mmap mode, and change it to be the default mode. This should also help to reduce CPU usage. Feel free to rebase those patches and apply into your tvtime tree, if you want. Cheers, 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
