Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Tue, Aug 4, 2009 at 4:12 PM, Hans Verkuilhverk...@xs4all.nl wrote: Hi all, During this years Plumbers Conference I will be organizing a session (or possibly more than one) on what sort of new V4L2 APIs are needed to support the new SoC devices. These new APIs should also solve the problem of how to find all the related alsa/fb/ir/dvb devices that a typical video device might create. A proposal was made about a year ago (note that this is a bit outdated by now, but the basics are still valid): http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html In the past year the v4l2 core has evolved enough so that we can finally start thinking about this for real. I would like to know who will be attending this conference. I also urge anyone who is working in this area and who wants to have a say in this to attend the conference. The goal is to prepare a new RFC with a detailed proposal on the new APIs that are needed to fully support all the new SoCs. So the more input we get, the better the end-result will be. Early-bird registration is still possible up to August 5th (that's tomorrow :-) ). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom I've been hardly trying to attend the conference but I'm afraid not gonna make it. But going to try to arrange the characteristics of the H/W I'm working on in a brief document and also expected new V4P2 APIs. I'll let you know when I finish my documentation. I know this is a good chance to discuss about where the video4linux for SoC platforms to go and I'm desperately looking forward to participate. but my business trip depends on the approval of my boss. Thus I'm very disappointed that I can't make it. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
Problem with OSPrey 240e
Hello, all: I'm new to capture card. I have a osprey 240e card. But I don't know how to make it work. I read the cardlist.bttv, there is no 240e in it. I modprobe bttv, and it can't recognise the card. Anyone knows how to do with it? Thanks all. yours hongqian -- 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
How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
[Resent with an updated subject, this time CC'ing linux-arm-kernel] I've spent the last few days playing with get_user_pages() and mlock() and got some interesting results. It turned out that cache coherency comes into play at some point, making the overall problem more complex. Here's my current setup: - OMAP processor, based on an ARMv7 core - MMU and IOMMU - VIPT non-aliasing data cache - video capture driver that transfers data to memory using DMA - video capture application that pass userspace pointers to video buffers to the driver My goal is to make sure that, upon DMA completion, the correct data will be available to the userspace application. The first problem was to pin pages to memory, to make sure they will not be freed when the DMA is in progress. videobug-dma-sg uses get_user_pages() for that, and Hugh Dickins nicely explained to me why this is enough. The second problem is to ensure cache coherency. As the userspace application will read data from the video buffers, those buffers will end up being cached in the processor's data cache. The driver does need to invalidate the cache before starting the DMA operation (userspace could in theory write to the buffers, but the data will be overwritten by DMA anyway, so there's no need to clean the cache). As the cache is of the VIPT (Virtual Index Physical Tag) type, cache invalidation can either be done globally (in which case the cache is flushed instead of being invalidated) or based on virtual addresses. In the last case the processor will need to look physical addresses up, either in the TLB or through hardware table walk. I can see three solutions to the DMA/cache problem. 1. Flushing the whole data cache right before starting the DMA transfer. There's no API for that in the ARM architecture, so a whole I+D cache is required. This is quite costly, we're talking about around 30 flushes per second, but it doesn't involve the MMU. That's the solution that I currently use. 2. Invalidating only the cache lines that store video buffer data. This requires a TLB lookup or a hardware table walk, so the userspace application MM context needs to be available (no problem there as where's flushing in userspace context) and all pages need to be mapped properly. This can be a problem as, as Hugh pointed out, pages can still be unmapped from the userspace context after get_user_pages() returns. I have experienced one oops due to a kernel paging request failure: Unable to handle kernel paging request at virtual address 44e12000 pgd = c8698000 [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= Internal error: Oops: 817 [#1] PREEMPT PC is at v7_dma_inv_range+0x2c/0x44 Fixing this requires more investigation, and I'm not sure how to proceed to find out if the page fault is really caused by pages being unmapped from the userspace context. Help would be appreciated. 3. Mark the pages as non-cacheable. Depending on how the buffers are then used by userspace, the additional cache misses might destroy any benefit I would get from not flushing the cache before DMA. I'm not sure how to mark a bunch of pages as non-cacheable though. What usually happens is that video drivers allocate DMA-coherent memory themselves, but in this case I need to deal with an arbitrary buffer allocated by userspace. If someone has any experience with this, it would be appreciated. Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Sun, 2 Aug 2009 12:10:04 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
following:
- v4l: introduce string control support.
Hans,
This looks very weird:
+/* The following two functions really belong in v4l2-common, but that
causes
+ a circular dependency between modules. We need to think about this,
but
+ for now this will do. */
+
+/* Return non-zero if this control is of type VALUE64.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_value64(u32 id)
+{
+ return 0;
+}
+
+/* Return non-zero if this control is a pointer type. Currently only
+ * type STRING is a pointer type.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_pointer(u32 id)
+{
+ return 0;
+}
+
...
+ } else if (ctrl_is_value64(kctrl-id)) {
+ if (copy_in_user(kctrl-value64, uctrl-value64,
+sizeof(uctrl-value64)))
+ return -EFAULT;
...
+ if (ctrl_is_value64(kctrl-id)) {
+ if (copy_in_user(uctrl-value64, kctrl-value64,
+sizeof(uctrl-value64)))
+ return -EFAULT;
+ } else if (!ctrl_is_pointer(kctrl-id)
+ copy_in_user(uctrl-value, kctrl-value,
+sizeof(uctrl-value))) {
Why do you need two routines that will always return zero? Why to create a
code
that will never be used? v4l2-compat-ioctl32.c is already complex enough
without adding any bogus code.
When the RDS encoder driver from Eduardo is added, then he will add the
string controls to ctrl_is_pointer() since his driver is the first to
actually implement string controls.
There is indeed no value64 control yet, but I think it is wise to at least
have the code in place to correctly handle such controls. I can remove
that if you want.
I noticed that you're also renaming the names of some fields there:
- struct v4l2_ext_control __user *ucontrols;
- struct v4l2_ext_control __user *kcontrols = kp-controls;
+ struct v4l2_ext_control __user *uctrl;
+ struct v4l2_ext_control __user *kctrl = kp-controls;
I dunno why you decided to do it, but having this together with the
changes at
v4l2-compat-ioctl32.c makes the code even harder to understand. Could you
please move the v4l2-compat-ioctl32 cosmetic changes like above into a
separate patch?
OK. It was done to avoid creating lots of 'longer than 80 characters'
warnings.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: [Resent with an updated subject, this time CC'ing linux-arm-kernel] I've spent the last few days playing with get_user_pages() and mlock() and got some interesting results. It turned out that cache coherency comes into play at some point, making the overall problem more complex. Here's my current setup: - OMAP processor, based on an ARMv7 core - MMU and IOMMU - VIPT non-aliasing data cache - video capture driver that transfers data to memory using DMA - video capture application that pass userspace pointers to video buffers to the driver My goal is to make sure that, upon DMA completion, the correct data will be available to the userspace application. The first problem was to pin pages to memory, to make sure they will not be freed when the DMA is in progress. videobug-dma-sg uses get_user_pages() for that, and Hugh Dickins nicely explained to me why this is enough. The second problem is to ensure cache coherency. As the userspace application will read data from the video buffers, those buffers will end up being cached in the processor's data cache. The driver does need to invalidate the cache before starting the DMA operation (userspace could in theory write to the buffers, but the data will be overwritten by DMA anyway, so there's no need to clean the cache). You'll need to clean the write buffers, otherwise the CPU may have data queued that it has yet to write back to memory. As the cache is of the VIPT (Virtual Index Physical Tag) type, cache invalidation can either be done globally (in which case the cache is flushed instead of being invalidated) or based on virtual addresses. In the last case the processor will need to look physical addresses up, either in the TLB or through hardware table walk. I can see three solutions to the DMA/cache problem. 1. Flushing the whole data cache right before starting the DMA transfer. There's no API for that in the ARM architecture, so a whole I+D cache is required. This is quite costly, we're talking about around 30 flushes per second, but it doesn't involve the MMU. That's the solution that I currently use. 2. Invalidating only the cache lines that store video buffer data. This requires a TLB lookup or a hardware table walk, so the userspace application MM context needs to be available (no problem there as where's flushing in userspace context) and all pages need to be mapped properly. This can be a problem as, as Hugh pointed out, pages can still be unmapped from the userspace context after get_user_pages() returns. I have experienced one oops due to a kernel paging request failure: If you already know the virtual addresses of the buffers, why do you need a TLB lookup (or am I being dense here?) Unable to handle kernel paging request at virtual address 44e12000 pgd = c8698000 [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= Internal error: Oops: 817 [#1] PREEMPT PC is at v7_dma_inv_range+0x2c/0x44 Fixing this requires more investigation, and I'm not sure how to proceed to find out if the page fault is really caused by pages being unmapped from the userspace context. Help would be appreciated. 3. Mark the pages as non-cacheable. Depending on how the buffers are then used by userspace, the additional cache misses might destroy any benefit I would get from not flushing the cache before DMA. I'm not sure how to mark a bunch of pages as non-cacheable though. What usually happens is that video drivers allocate DMA-coherent memory themselves, but in this case I need to deal with an arbitrary buffer allocated by userspace. If someone has any experience with this, it would be appreciated. Regards, Laurent Pinchart --- List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- 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
Hauppauge WinTV HVR-900HD support?
Hi, in an earlier post I was responded to that my old WinTV USB 1 Tuner would never work under Linux due to bad and complicated coding which (since no one uses that tuner anymore) will never be looked at. So I am in need of a new tuner! This is a dilemma as I need analog TV since I will be using it for watching stuff through a satellite receiver but also analog terrestrial TV too as where I will be taking it to doesn't have digital TV at best the have cable. I was considering going for the Hauppauge WinTV HVR-900HD. I am not sure if it will be compatible though with the global regions I will use it in which is UK that I know it has support for as I will buy from here which is PAL I but then also Turkey which I think is PAL Beta if I'm not mistaken?? More importantly though is it supported under Linux?? I use KUbuntu 9.04 which is pretty up to date. I am just a bit worried about this part since the site says that as of June 2008 there is no support... of course we are in August 2009 so maybe in a year it might have been integrated into the later kernels?? Taken from here: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H What's everyone's verdict? Any suggestions would be great! --Kaya -- 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: Hauppauge WinTV HVR-900HD support?
Kaya, On Thu, Aug 6, 2009 at 7:53 AM, Kaya Samansamank...@netscape.net wrote: Hi, in an earlier post I was responded to that my old WinTV USB 1 Tuner would never work under Linux due to bad and complicated coding which (since no one uses that tuner anymore) will never be looked at. I don't think that's true -- I didn't see your earlier post, but I can only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 chipsets, supported by the usbvision driver -- did you try that? So I am in need of a new tuner! Better off getting a new one anyway, since analog TV will disappear eventually and DTV is all that will be around. This is a dilemma as I need analog TV since I will be using it for watching stuff through a satellite receiver but also analog terrestrial TV too as where I will be taking it to doesn't have digital TV at best the have cable. I was considering going for the Hauppauge WinTV HVR-900HD. I am not sure if it will be compatible though with the global regions I will use it in which is UK that I know it has support for as I will buy from here which is PAL I but then also Turkey which I think is PAL Beta if I'm not mistaken?? More importantly though is it supported under Linux?? I use KUbuntu 9.04 which is pretty up to date. I am just a bit worried about this part since the site says that as of June 2008 there is no support... of course we are in August 2009 so maybe in a year it might have been integrated into the later kernels?? Taken from here: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H What's everyone's verdict? Any suggestions would be great! The HVR-900H is currently *not* supported under Linux, and it does not seem that it will get such support anytime in the near future, unfortunately. Please note, I am only speaking for the HVR-900H ... other flavors of the HVR900 are fully functional and supported, just not the H version. If you're looking for a well-supported USB hybrid device, I would recommend one of the standard HVR-900 sticks, or even better, the HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder -- this is perfect if you intend to use the device for recordings. HVR1900 is fully supported under Linux. I hope this helps. Regards, Mike -- 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: Hauppauge WinTV HVR-900HD support?
Michael Krufky wrote: Kaya, On Thu, Aug 6, 2009 at 7:53 AM, Kaya Samansamank...@netscape.net wrote: I don't think that's true -- I didn't see your earlier post, but I can only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 chipsets, supported by the usbvision driver -- did you try that? Better off getting a new one anyway, since analog TV will disappear eventually and DTV is all that will be around. The HVR-900H is currently *not* supported under Linux, and it does not seem that it will get such support anytime in the near future, unfortunately. Please note, I am only speaking for the HVR-900H ... other flavors of the HVR900 are fully functional and supported, just not the H version. If you're looking for a well-supported USB hybrid device, I would recommend one of the standard HVR-900 sticks, or even better, the HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder -- this is perfect if you intend to use the device for recordings. HVR1900 is fully supported under Linux. I hope this helps. Regards, Mike Thanks for the response Mike! You claim there is a Hauppauge HVR-1900... I am looking on the www.hauppauge.co.uk website and all I see is a 1400 which is SMC slot?? In fact just checked hauppauge.com and there seems to be a 1950 model! Perhaps it hasn't been released yet or maybe I haven't found it. Is it HD compatible like the HVR-900H model? --This is not so important but a nicety none the less :-) I will forward my previous post to you directly! Regards, Kaya -- 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: Hauppauge WinTV HVR-900HD support?
On Thu, Aug 6, 2009 at 9:07 AM, Kaya Samansamank...@netscape.net wrote: Michael Krufky wrote: Kaya, On Thu, Aug 6, 2009 at 7:53 AM, Kaya Samansamank...@netscape.net wrote: I don't think that's true -- I didn't see your earlier post, but I can only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 chipsets, supported by the usbvision driver -- did you try that? Better off getting a new one anyway, since analog TV will disappear eventually and DTV is all that will be around. The HVR-900H is currently *not* supported under Linux, and it does not seem that it will get such support anytime in the near future, unfortunately. Please note, I am only speaking for the HVR-900H ... other flavors of the HVR900 are fully functional and supported, just not the H version. If you're looking for a well-supported USB hybrid device, I would recommend one of the standard HVR-900 sticks, or even better, the HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder -- this is perfect if you intend to use the device for recordings. HVR1900 is fully supported under Linux. I hope this helps. Regards, Mike Thanks for the response Mike! You claim there is a Hauppauge HVR-1900... I am looking on the www.hauppauge.co.uk website and all I see is a 1400 which is SMC slot?? HVR1400 is expresscard. HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog standards) HVR1900 is the one I am recommending for you. Maybe the website you're looking at needs updating -- the HVR1900 has been available already for quite some time. Regards, Mike -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
On Thu, Aug 6, 2009 at 9:54 AM, xwang1...@email.it wrote: Hi, I want to inform you that thanks to Douglas Schilling Landgraf, the first point (automatic recognition of the device when plugged in) ha been resolved (using his development tree driver). I've tried to scan for digital channels again and the result has not changed but in the dmesg attached there are a lot of messages created during the scan process. I hope they are useful to solve at list the issue related with the digital scanning. Thank you, Xwang snip Yeah, I've seen that before. Open up em28xx-dvb.c, and move the following: case EM2880_BOARD_EMPIRE_DUAL_TV: from line 402 to line 492. So it should look like this: case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900: case EM2880_BOARD_EMPIRE_DUAL_TV: dvb-frontend = dvb_attach(zl10353_attach, em28xx_zl10353_xc3028_no_i2c_gate, dev-i2c_adap); Then unplug the device, recompile, reinstall and see if the dvb starts working. 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: Hauppauge WinTV HVR-900HD support?
On Thu, Aug 6, 2009 at 9:33 AM, Kaya Samansamank...@netscape.net wrote: Michael Krufky wrote: HVR1400 is expresscard. HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog standards) HVR1900 is the one I am recommending for you. Maybe the website you're looking at needs updating -- the HVR1900 has been available already for quite some time. Regards, Mike Thanks Mike, I managed to find it finally on Amazon.co.uk which claimed that it was available from June 2007! That might explain why it's not on the Hauppauge website as it is most likely getting replaced I actually expected this to be one of those cute USB keys but this thing resembles a set top box :-) I think the WinTV HVR-900 maybe a better option as it is supported. I am guessing that this is the same thing as the H model without the HD support? No, I recommended the HVR1900 because *IT* is fully supported, and is *not* getting replaced. HVR900 got replaced. HVR1900 is not as large as a set top box, but it is bigger than the usb sticks, and uses a power brick, for the mpeg encoder. It is on the Hauppauge web site, you probably just overlooked it. -Mike -- 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: Linux Plumbers Conference 2009: V4L2 API discussions
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav Sent: Tuesday, August 04, 2009 12:13 PM To: Hans Verkuil; linux-media@vger.kernel.org Cc: eduardo.valen...@nokia.com; davinci-linux-open- sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus Damm; Dongsoo, Nathaniel Kim Subject: RE: Linux Plumbers Conference 2009: V4L2 API discussions -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Hans Verkuil Sent: Tuesday, August 04, 2009 12:42 PM To: linux-media@vger.kernel.org Cc: eduardo.valen...@nokia.com; davinci-linux-open- sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus Damm; Dongsoo, Nathaniel Kim Subject: Linux Plumbers Conference 2009: V4L2 API discussions Hi all, During this years Plumbers Conference I will be organizing a session (or possibly more than one) on what sort of new V4L2 APIs are needed to support the new SoC devices. These new APIs should also solve the problem of how to find all the related alsa/fb/ir/dvb devices that a typical video device might create. A proposal was made about a year ago (note that this is a bit outdated by now, but the basics are still valid): http://www.archivum.info/video4linux-list%40redhat.com/2008- 07/msg00371.html In the past year the v4l2 core has evolved enough so that we can finally start thinking about this for real. I would like to know who will be attending this conference. I also urge anyone who is working in this area and who wants to have a say in this to attend the conference. The goal is to prepare a new RFC with a detailed proposal on the new APIs that are needed to fully support all the new SoCs. So the more input we get, the better the end-result will be. [Hiremath, Vaibhav] Hi Hans, I will be attending the conference and along with above mentioned RFC I would want to discuss some of the open issues, forthcoming TI devices, their complexity and required software interfaces (media processor (as you mentioned above)) and similar stuff. Hans, Vaibhav, I'll be attending this conference too. I just got approval from my boss ;). I'm starting to take the v4l2_subdev migration task as a high priority now, since most of the stability related issues in some proprietary platform are gone now. :) Actually, I'm also interested on the discussions about the Preview/Resizer Wrappers. Meet you there. Regards, Sergio I will work with you offline before sharing the details here with the community. Thanks, Vaibhav Hiremath Early-bird registration is still possible up to August 5th (that's tomorrow :-) ). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- source -- To unsubscribe from this list: send the line unsubscribe linux-omap 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,RFC] Drop non-unlocked ioctl support in v4l2-dev.c
Hi Laurent, Hi everybody, this patch moves the BKL one level down by removing the non-unlocked ioctl in v4l2-dev.c and calling lock_kernel/unlock_kernel in the unlocked_ioctl handler if the driver only supports locked ioctl. Opinions/comments/applause/kicks ? I've been thinking about this as well, and my idea was to properly implement this by letting the v4l core serialize ioctls if the driver doesn't do its own serialization (either through mutexes or lock_kernel). The driver can just set a flag in video_device if it wants to do serialization manually, otherwise the core will serialize using a mutex and we should be able to completely remove the BKL from all v4l drivers. I was actually planning an RFC for this myself, but you've beaten me to it :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
Ok, I've made the change and now the digital tv works perfectly. So now I should test the analog tv, but I fear to have another kernel panic. Is there something I can do before testing so that to be sure that at least all the file system are in a safety condition even if a kernel panic happens. I'm wondering if it is the case, for example, to umount them and remount in read only mode so that if I have to turn off the pc, nothing can be corrupted (is it so?). What do you suggest? In case, how can I temporarly umount and remout the file systems in read only mode? Should I use alt+sys+S followed by alt+sys+U? Can I use such commands while I'm in KDE? Thank you, Xwang Douglas Schilling Landgraf ha scritto: Hello Xwang, Could you please try the bellow suggestion? If you want I can make this change in my development tree and you can test from there. Let me know the results Cheers, Douglas On Thu, 6 Aug 2009 10:17:28 -0400 Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Aug 6, 2009 at 9:54 AM, xwang1...@email.it wrote: Hi, I want to inform you that thanks to Douglas Schilling Landgraf, the first point (automatic recognition of the device when plugged in) ha been resolved (using his development tree driver). I've tried to scan for digital channels again and the result has not changed but in the dmesg attached there are a lot of messages created during the scan process. I hope they are useful to solve at list the issue related with the digital scanning. Thank you, Xwang snip Yeah, I've seen that before. Open up em28xx-dvb.c, and move the following: case EM2880_BOARD_EMPIRE_DUAL_TV: from line 402 to line 492. So it should look like this: case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900: case EM2880_BOARD_EMPIRE_DUAL_TV: dvb-frontend = dvb_attach(zl10353_attach, em28xx_zl10353_xc3028_no_i2c_gate, dev-i2c_adap); Then unplug the device, recompile, reinstall and see if the dvb starts working. Devin -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
On Thu, Aug 6, 2009 at 11:16 AM, xwang1...@email.it wrote: Ok, I've made the change and now the digital tv works perfectly. So now I should test the analog tv, but I fear to have another kernel panic. Is there something I can do before testing so that to be sure that at least all the file system are in a safety condition even if a kernel panic happens. I'm wondering if it is the case, for example, to umount them and remount in read only mode so that if I have to turn off the pc, nothing can be corrupted (is it so?). What do you suggest? In case, how can I temporarly umount and remout the file systems in read only mode? Should I use alt+sys+S followed by alt+sys+U? Can I use such commands while I'm in KDE? Thank you, Xwang Glad to hear it's working now. I will add the patch and issue a PULL request to get it into the mainline (I had to do this already for several other boards). Regarding your concerns on panic, as long as you have a modern filesystem like ext3, and you don't have alot of applications running which are doing writes, a panic is a pretty safe event. I panic my machine many times a week and never have any problems. Cheers, 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: Hauppauge WinTV HVR-900HD support?
No, I recommended the HVR1900 because *IT* is fully supported, and is *not* getting replaced. HVR900 got replaced. HVR1900 is not as large as a set top box, but it is bigger than the usb sticks, and uses a power brick, for the mpeg encoder. It is on the Hauppauge web site, you probably just overlooked it. -Mike Ok, now I am so sorry and I feel really silly but I can't find it. I have tried hauppauge.co.uk and under HVR-external all I get is 900HD, 900, and 1400: http://www.hauppauge.co.uk/site/products/prods_hvr_external.html now, I even did a search for the 1900 and found nothing on hauppauge search link??? Sure it came up with the 1950 model but no 1900. On top of that I tried www.dabs.com and www.misco.co.uk both of which have the 900 but no 1900. am I missing something or have I just totally gone insane over the last few hours??? --K -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: Hi Ben, On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: [snip] The second problem is to ensure cache coherency. As the userspace application will read data from the video buffers, those buffers will end up being cached in the processor's data cache. The driver does need to invalidate the cache before starting the DMA operation (userspace could in theory write to the buffers, but the data will be overwritten by DMA anyway, so there's no need to clean the cache). You'll need to clean the write buffers, otherwise the CPU may have data queued that it has yet to write back to memory. Good points, thanks. I thought this should have been taken care of by the CPU specific dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, v7_dma_inv_range does not drain the write buffer; and the v6_dma_inv_range does that in the end of all the cache maintenance operaitons. So this is probably something Russel can clarify. As the cache is of the VIPT (Virtual Index Physical Tag) type, cache invalidation can either be done globally (in which case the cache is flushed instead of being invalidated) or based on virtual addresses. In the last case the processor will need to look physical addresses up, either in the TLB or through hardware table walk. I can see three solutions to the DMA/cache problem. 1. Flushing the whole data cache right before starting the DMA transfer. There's no API for that in the ARM architecture, so a whole I+D cache is required. This is quite costly, we're talking about around 30 flushes per second, but it doesn't involve the MMU. That's the solution that I currently use. 2. Invalidating only the cache lines that store video buffer data. This requires a TLB lookup or a hardware table walk, so the userspace application MM context needs to be available (no problem there as where's flushing in userspace context) and all pages need to be mapped properly. This can be a problem as, as Hugh pointed out, pages can still be unmapped from the userspace context after get_user_pages() returns. I have experienced one oops due to a kernel paging request failure: If you already know the virtual addresses of the buffers, why do you need a TLB lookup (or am I being dense here?) The virtual address is used to compute the cache lines index, and the physical address is then used when comparing the cache line tag. So the processor (or actually the CP15 coprocessor if I'm not wrong) does a TLB lookup to get the physical address during cache invalidation/flushing. Unable to handle kernel paging request at virtual address 44e12000 pgd = c8698000 [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= Internal error: Oops: 817 [#1] PREEMPT PC is at v7_dma_inv_range+0x2c/0x44 Fixing this requires more investigation, and I'm not sure how to proceed to find out if the page fault is really caused by pages being unmapped from the userspace context. Help would be appreciated. 3. Mark the pages as non-cacheable. Depending on how the buffers are then used by userspace, the additional cache misses might destroy any benefit I would get from not flushing the cache before DMA. I'm not sure how to mark a bunch of pages as non-cacheable though. What usually happens is that video drivers allocate DMA-coherent memory themselves, but in this case I need to deal with an arbitrary buffer allocated by userspace. If someone has any experience with this, it would be appreciated. Another approach is working from a different direction: the kernel allocates the non-cached buffer and then mmap() into user space. I have done that in similar situation to try to achieve zero-copy. David -- 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
Syntek Driver ...
Greetings ... I was wondering if anybody has looked at the Syntek Driver stk11xx at http://sourceforge.net/projects/syntekdriver/files/ ... This driver is meant to have updates for the EasyCap USB video capture device ... Would be great to have included in the main line Video4Linux and then up stream Kernel ... Pretty please!! Mailed LeeT P.S. Hans de Goede suggested I post here ... -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: On Thu, 6 Aug 2009, Hans Verkuil wrote: Why do you need two routines that will always return zero? Why to create a code that will never be used? v4l2-compat-ioctl32.c is already complex enough without adding any bogus code. When the RDS encoder driver from Eduardo is added, then he will add the string controls to ctrl_is_pointer() since his driver is the first to actually implement string controls. Could one of the upper bits of the control id be used as a flag? It would make it a lot easier to check the control's type than by using some inline function with a giant case statement that needs to be updated each time a new control is added. No, you can't. That would require users to OR that flag each time you want to use such a control. My original plan was to just check for a non-zero size field, the theory being that applications would set the old reserved field to 0. Unfortunately, several apps do not init those reserved fields, so they would fail. Note to ourselves: the next time we require apps to zero reserved fields we really have to check that they do and return an error otherwise... Anyway, I expect that these functions are a temporary measure anyway. Once we can move the control handling to the v4l2 framework this sort of info should be available readily from the framework without requiring such ugly switches. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was Is get_user_pages() enough to prevent pages from being swapped out ?)
David Xiao wrote: Another approach is working from a different direction: the kernel allocates the non-cached buffer and then mmap() into user space. I have done that in similar situation to try to achieve zero-copy. open(O_DIRECT) does DMA to arbitrary pages allocated by userspace, and O_DIRECT is used by some important applications, so the problem still needs to be solved in general. -- Jamie -- 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
sn9c20x driver seems ok, but no video
Hi folks, Trying to get a usb webcam based on SN9C20x driver working on Ubuntu. Loading the module, everything looks good (log output trimmed for easy reading): kernel: usb 7-3: new high speed USB device using ehci_hcd and address 4 kernel: usb 7-3: configuration #1 chosen from 1 choice kernel: sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:628F plugged-in. kernel: sn9c20x: Detected OV9650 Sensor. kernel: sn9c20x: Webcam device 0C45:628F is now controlling video device /dev/video0 kernel: input: SN9C20X Webcam as /class/input/input10 kernel: sn9c20x: No ack from I2C slave 0x30 for write to address 0x17 kernel: sn9c20x: Using yuv420 output format However, I've tried several different apps (cheese, Xsane, gstreamer, etc) but cannot see any video output. I confess to being completely ignorant on issues video, etc. :) If I type 'cat /dev/video0 j.dump', the green LED on camera comes on, and j.dump is filled with binary data. However, gst-launch shows this: # gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. WARNING: from element /pipeline0/v4l2src0: Failed to get current input on device '/dev/video0'. May be it is a radio device Additional debug info: v4l2_calls.c(756): gst_v4l2_get_input (): /pipeline0/v4l2src0: system error: Invalid argument ERROR: from element /pipeline0/v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2387): gst_base_src_start (): /pipeline0/v4l2src0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... I'm running Ubuntu Jaunty kernel (2.6.28) with Hardy userland. Any input/pointers would be most appreciated! And if there is a better list to post such a question, I'd appreciate it. I posted on micro...@googlegroups.com, but that list hasn't had a single message in more than 24 hours! Thanks, Chris -- Life is like Linux - it never stands still. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thu, 6 Aug 2009, Hans Verkuil wrote: On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: On Thu, 6 Aug 2009, Hans Verkuil wrote: Why do you need two routines that will always return zero? Why to create a code that will never be used? v4l2-compat-ioctl32.c is already complex enough without adding any bogus code. When the RDS encoder driver from Eduardo is added, then he will add the string controls to ctrl_is_pointer() since his driver is the first to actually implement string controls. Could one of the upper bits of the control id be used as a flag? It would make it a lot easier to check the control's type than by using some inline function with a giant case statement that needs to be updated each time a new control is added. No, you can't. That would require users to OR that flag each time you want to use such a control. My original plan was to just check for a non-zero There is no reason we need to allocated control IDs sequentially, is there? So just give string controls IDs in the range 0x8000 to 0x and then one can tell if a control is a string control be ANDing the id with (131). -- 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 6/9] drivers/media/dvb: Use dst_type field instead of type_flags
From: Julia Lawall ju...@diku.dk
It seems from other code that it is the dst_type field rather than the
type_flags field that contains values of the form DST_TYPE_IS...
The type_flags field contains values of the form DST_TYPE_HAS...
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@@ struct dst_state E; @@
(
*E.type_flags ==
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
|
*E.type_flags !=
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/dvb/bt8xx/dst.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/media/dvb/bt8xx/dst.c~drivers-media-dvb-use-dst_type-field-instead-of-type_flags
drivers/media/dvb/bt8xx/dst.c
---
a/drivers/media/dvb/bt8xx/dst.c~drivers-media-dvb-use-dst_type-field-instead-of-type_flags
+++ a/drivers/media/dvb/bt8xx/dst.c
@@ -1059,7 +1059,7 @@ static int dst_get_tuner_info(struct dst
dprintk(verbose, DST_ERROR, 1, DST type has TS=188);
}
if (state-board_info[0] == 0xbc) {
- if (state-type_flags != DST_TYPE_IS_ATSC)
+ if (state-dst_type != DST_TYPE_IS_ATSC)
state-type_flags |= DST_TYPE_HAS_TS188;
else
state-type_flags |= DST_TYPE_HAS_NEWTUNE_2;
_
--
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 7/9] stk-webcam: read buffer overflow
From: Roel Kluin roel.kl...@gmail.com
It tested the value of stk_sizes[i].m before checking whether i was in range.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Trent Piepho xy...@speakeasy.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/media/video/stk-webcam.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/media/video/stk-webcam.c~stk-webcam-read-buffer-overflow
drivers/media/video/stk-webcam.c
--- a/drivers/media/video/stk-webcam.c~stk-webcam-read-buffer-overflow
+++ a/drivers/media/video/stk-webcam.c
@@ -1050,8 +1050,8 @@ static int stk_setup_format(struct stk_c
depth = 1;
else
depth = 2;
- while (stk_sizes[i].m != dev-vsettings.mode
-i ARRAY_SIZE(stk_sizes))
+ while (i ARRAY_SIZE(stk_sizes)
+ stk_sizes[i].m != dev-vsettings.mode)
i++;
if (i == ARRAY_SIZE(stk_sizes)) {
STK_ERROR(Something is broken in %s\n, __func__);
_
--
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 v0 0/5] V4L: vpif_capture driver for DM6467
From: Muralidharan Karicheri m-kariche...@ti.com This patch series add support for VPIF Capture Driver on DM6467. VPIF (Video Port Interface) has two channels for capture video or Raw image data. Currently only video capture is supported using TVP5147 on each of the channel. That means two simultaneous capture of NTSC/PAL video is possible using this driver. Following are the patches in this series:- 1) DaVinci - re-structuring code to support vpif capture driver 2) V4L : vpif updates for DM6467 vpif capture driver 3) V4L : vpif display - updates to support vpif capture on DM6467 4) V4L : vpif_capture driver for DM6467 5) V4L : vpif capture - Kconfig and Makefile changes Mandatory reviewers : Hans Verkuil hverk...@xs4all.nl Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v0 1/5] DaVinci - re-structuring code to support vpif capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
This patch makes the following changes:-
1) Modify vpif_subdev_info to add board_info, routing information
and vpif interface configuration. Remove addr since it is
part of board_info
2) Add code to setup channel mode and input decoder path for
vpif capture driver
NOTE: This patch is dependent on the patch from Chaithrika for vpif display.
Also
the arch sepcific files are manually merged to linux-davinci tree before
creating
this patch. So this is only for review. Final patch to be merged will be created
later
Mandatory reviewers : Hans Verkuil hverk...@xs4all.nl
Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
arch/arm/mach-davinci/board-dm646x-evm.c| 179 +-
arch/arm/mach-davinci/dm646x.c | 54 +++-
arch/arm/mach-davinci/include/mach/dm646x.h | 50 +++-
3 files changed, 263 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 38a1022..cb4246b 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,7 +33,7 @@
#include linux/i2c/at24.h
#include linux/i2c/pcf857x.h
#include linux/etherdevice.h
-
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -75,6 +75,14 @@
#define VIDCH2CLK (BIT(10))
#define VIDCH3CLK (BIT(11))
+#define VIDCH1CLK (BIT(4))
+#define TVP7002_INPUT (BIT(4))
+#define TVP5147_INPUT (~BIT(4))
+#define VPIF_INPUT_ONE_CHANNEL (BIT(5))
+#define VPIF_INPUT_TWO_CHANNEL (~BIT(5))
+#define TVP5147_CH0tvp514x-0
+#define TVP5147_CH1tvp514x-1
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 0),
@@ -348,7 +356,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO(cpld_reg0, 0x3a),
},
{
- I2C_BOARD_INFO(cpld_video, 0x3B),
+ I2C_BOARD_INFO(cpld_video, 0x3b),
},
};
@@ -400,14 +408,18 @@ static int set_vpif_clock(int mux_mode, int hd)
return 0;
}
-static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
+static struct vpif_subdev_info dm646x_vpif_subdev[] = {
{
- .addr = 0x2A,
.name = adv7343,
+ .board_info = {
+ I2C_BOARD_INFO(adv7343, 0x2a),
+ },
},
{
- .addr = 0x2C,
.name = ths7303,
+ .board_info = {
+ I2C_BOARD_INFO(ths7303, 0x2c),
+ },
},
};
@@ -417,7 +429,7 @@ static const char *output[] = {
S-Video,
};
-static struct vpif_config dm646x_vpif_config = {
+static struct vpif_display_config dm646x_vpif_display_config = {
.set_clock = set_vpif_clock,
.subdevinfo = dm646x_vpif_subdev,
.subdev_count = ARRAY_SIZE(dm646x_vpif_subdev),
@@ -426,6 +438,158 @@ static struct vpif_config dm646x_vpif_config = {
.card_name = DM646x EVM,
};
+/**
+ * setup_vpif_input_path()
+ * @channel: channel id (0 - CH0, 1 - CH1)
+ * @sub_dev_name: ptr sub device name
+ *
+ * This will set vpif input to capture data from tvp514x or
+ * tvp7002.
+ */
+static int setup_vpif_input_path(int channel, const char *sub_dev_name)
+{
+ int err = 0;
+ int val;
+
+ /* for channel 1, we don't do anything */
+ if (channel != 0)
+ return 0;
+
+ if (NULL == cpld_client)
+ return -EFAULT;
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ if (!strcmp(sub_dev_name, TVP5147_CH0) ||
+ !strcmp(sub_dev_name, TVP5147_CH1))
+ val = TVP5147_INPUT;
+ else
+ val |= TVP7002_INPUT;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+ return 0;
+}
+
+/**
+ * setup_vpif_input_channel_mode()
+ * @mux_mode: mux mode. 0 - 1 channel or (1) - 2 channel
+ *
+ * This will setup input mode to one channel (TVP7002) or 2 channel (TVP5147)
+ */
+static int setup_vpif_input_channel_mode(int mux_mode)
+{
+ int err = 0;
+ int val;
+ u32 value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val 0)
+ return val;
+
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ if (mux_mode) {
+ val = VPIF_INPUT_TWO_CHANNEL;
+ value |= VIDCH1CLK;
+ } else {
+ val |= VPIF_INPUT_ONE_CHANNEL;
+ value = ~VIDCH1CLK;
+ }
+ __raw_writel(value, base +
[PATCH v0 2/5] V4L : vpif updates for DM6467 vpif capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes done for vpif driver to support vpif capture:-
1) Current version of display driver defined vpif register
space as part for vpif display platform driver resource
This is not correct since vpif is common across capture
and display drivers. So the resource iomap function is
moved to this module
2) Since there are common registers, a spinlock is added for
mutual exclusion.
NOTE: This is only for review. Final patch for merge will be sent later
This patch is dependent on the patch from Chaithrika for vpif display
Mandatory reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpif.c | 76 ---
drivers/media/video/davinci/vpif.h | 48 ++-
2 files changed, 98 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index aa77126..3b8eac3 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -19,7 +19,11 @@
#include linux/init.h
#include linux/module.h
+#include linux/platform_device.h
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct vpif_params
*vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams-params.raw_params.fid_pol);
+ vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.vd_pol);
+ vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.hd_pol);
+ vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams-params.raw_params.data_sz)
+ value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res-start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(vpif_lock);
+ dev_info(pdev-dev, vpif probe success\n);
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res-start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = vpif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/videodev2.h
#include mach/hardware.h
+#include mach/dm646x.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define
Re: PVR x50 corrupts ATSC 115 streams
On Tue, Feb 17, 2009 at 09:53:35AM -0600, David Engel wrote: I moved the disks and tuner cards (2 Kworld ATSC 115s, 1 Hauppauge PVR 250 and 1 Hauppauge PVR 350) to the new system (AMD X2 3600 CPU and Biostar TForce 550 motherboard). Things went fairly smoothly and I seemed to have full stability again for the first time in several weeks. Then, I started noticing frequent corruption in some of my claar QAM recordings from the ATSC 115 cards. When the corruption is present, it occurs every few seconds -- a splotch of garbage in the picture here, a stutter and a skipped frame there. Sure enough, MythTV and mplayer both report CRC, damage, splice and other errors when playing the streams. I finally determined the stream corruption happens if and only if one of the PVR x50 cards is being used at the same time. If only the ATSC 115s are used, there is no corruption. As soon as either of the PVr X50 is used with an ATSC 115, there is corruption. I tested with the stock drivers from the 2.6.27.17 kernel and from current Hg. The corruption happens with both sets of drivers. FWIW, I haven't noticed any corruption with the analog recordings from the PVR x50s. Does anyone know what might be going on? These very same tuner cards worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7 motherboard) for close to two years. I want to follow up on this for the benefit of anyone who runs across it in the archives. The short version is the problem appears to have been caused by the motherboard. My guess is noise or a grounding problem. The slightly longer version is I've been using a non-optimal arrangement of tuner cards to avoid the corruption problems described above. About two weeks ago, I started having problems with one and then multiple SATA disks. Process of elimination led to the motherboard. I tried the previously troublesome combination of cards today with the new motherboard and no longer see the problem. David -- David Engel da...@istwok.net -- 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
