Re: [ANNOUNCE] git tree repositories
Hi Mauro, I would like to personally thank you for spending time on git support at linuxtv.org. Git support was a long-awaited feature for many developers (and I certainly was one of them). All the work done behind the scene on linuxtv.org isn't seen by end-users and can thus be less rewarding than working on the code. However, it's of critical importance to make the development process as smooth as possible. For that reason, thank you again. Thanks to Douglas too for agreeing to manage backports. Getting the latest version of our drivers working on older kernels make the test base much larger, leading to better quality code (or at least to more bug reports :-)). -- 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: [ANNOUNCE] git tree repositories
On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! A big thank you also from me. This is really outstanding work you're doing there and it's highly appreciated. I do have one proposal: parts of our hg tree are independent of git: v4l2-apps, possibly some firmware build code (not 100% sure of that), v4l_experimental, perhaps some documentation stuff. My proposal is that we make a separate hg or git tree for those. It will make it easier to package by distros and it makes it easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work by moving non-essential code out of the compat hg tree. In terms of the out-of-tree building system evolution (e. g. the building system concept behind the -hg tree), If people think it is worthy enough, maybe later this could also be converted also to -git, but preserving the building system and the backport patches. Another alternative would be to split the building systems and the backport patches, and apply them into the drivers/media files. I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of the time using distro-kernels in my productive environments and I'm replacing v4l/dvb drivers with the one from v4l-dvb. One step into the direction of a solution might be: Why not including the v4l-dvb/v4l/Makefile and the related files into that separate repository Hans is describing here and then telling 'make' to make links to ../../v4l-dvb/ instead of ../linux as of today. But I don't know how to solve the ifdef KERNEL_VERSION for having backward compatibility in the source files. Maybe with a patch for each kernel version? BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. best regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 5/7] V4L: Events: Limit event queue length
Hi Hans, On Monday 18 January 2010 13:58:09 Hans Verkuil wrote: On Tue, 22 Dec 2009, Sakari Ailus wrote: Limit event queue length to V4L2_MAX_EVENTS. If the queue is full any further events will be dropped. This patch also updates the count field properly, setting it to exactly to number of further available events. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- drivers/media/video/v4l2-event.c | 10 +- include/media/v4l2-event.h |5 + 2 files changed, 14 insertions(+), 1 deletions(-) [snip] diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h index b11de92..69305c6 100644 --- a/include/media/v4l2-event.h +++ b/include/media/v4l2-event.h @@ -28,6 +28,10 @@ #include linux/types.h #include linux/videodev2.h +#include asm/atomic.h + +#define V4L2_MAX_EVENTS1024 /* Ought to be enough for everyone. */ I think this should be programmable by the driver. Most drivers do not use events at all, so by default it should be 0 or perhaps it can check whether the ioctl callback structure contains the event ioctls and set it to 0 or some initial default value. And you want this to be controlled on a per-filehandle basis even. If I look at ivtv, then most of the device nodes will not have events, only a few will support events. And for one device node type I know that there will only be a single event when stopping the streaming, while another device node type will get an event each frame. Don't you mean per video node instead of per file handle ? In that case we could add a new field to video_device structure that must be initialized by drivers before registering the device. So being able to adjust the event queue dynamically will give more control and prevent unnecessary waste of memory resources. -- 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: [RFC v2 0/7] V4L2 file handles and event interface
Hi Hans, On Monday 18 January 2010 14:07:33 Hans Verkuil wrote: On Tue, 22 Dec 2009, Sakari Ailus wrote: Hi, Here's the second version of the V4L2 file handle and event interface patchset. Still RFC since I'd like to get more feedback on it. The first patch adds the V4L2 file handle support and the rest are for V4L2 events. The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called events): git://gitorious.org/omap3camera/mainline.git event The major change since the last one v4l2_fh structure is now part of driver's own file handle. It's used as file-private_data as well. I did this based on Hans Verkuil's suggestion. Sequence numbers and event queue length limitation is there as well. There are countless of smaller changes, too. A few notes on the patches: - I don't like the locking too much. Perhaps the file handle specific lock (events-lock) could be dropped in favour of the lock for v4l2_file_handle in video_device? - Poll. The V4L2 specifiction says: When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The current events for OMAP 3 ISP are related to streaming but not all might be in future. For example there might be some radio or DVB related events. I know for sure that we will have to be able to handle events when not streaming. E.g. events that tell when a HDMI connector was plugged in or when the EDID was read will need to arrive whether streaming is on or off. I agree with you. The V4L2 specification will then need to be changed, otherwise we won't be able to poll() for events. poll() wouldn't return immediately anymore if no buffer is queued or if the device isn't streaming. That might break existing applications (although we could argue that some of those applications are somehow broken already if they rely on such a weird feature). If we want to avoid disturbing existing applications we could still return POLLERR immediately when not streaming if no event has been subscribed to. - Sequence numbers are local to file handles. That is how it should be. - Subscribing V4L2_EVENT_ALL causes any other events to be unsubscribed. - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would be difficult to work around since this would require the event system to be aware of the driver private events as well. Good point. Perhaps attempting to unsubscribe a single event when EVENT_ALL has been subscribed should result in an error? I.e., you can only unsubscribe ALL when you subscribed to ALL in the first place. -- 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
CI Plus support for TT S2 3200
Does anyone know if the current Technotrend DVB-S2 S2-3200 with the CI daughter board supports the latest generation of CI+ CAMS and specified in http://www.ci-plus.com/ in non-legacy mode? I guess what I am asking is, can the hardware support full CI+, what would be involved software wise and has anyone looked at this? Pete -- 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: DM1105: could not attach frontend 195d:1105
Well, as I understood, GPIO15 drives reset for demod. dm1105 driver needs little patching. Igor, Not to hassle you, I'm sure you're very busy. Is this something I could undertake myself? If so, which driver would you recommend I copy from - I saw on the list that some drivers do their own GPIO management, and others use a generic GPIO layer. I presume we'd need to use the generic layer? Also, from your explanation it sounds like we need to set GPIO 15 to true before we attempt to attach. Is that correct? From my reading there are two GPIO registers (8 bits each), so we'd be bit masking bit 7 in the second GPIO register to 1, then sending that GPIO to the card? Thanks for any tips, Paul -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 5/7] V4L: Events: Limit event queue length
Hi Hans, On Monday 18 January 2010 13:58:09 Hans Verkuil wrote: On Tue, 22 Dec 2009, Sakari Ailus wrote: Limit event queue length to V4L2_MAX_EVENTS. If the queue is full any further events will be dropped. This patch also updates the count field properly, setting it to exactly to number of further available events. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- drivers/media/video/v4l2-event.c | 10 +- include/media/v4l2-event.h |5 + 2 files changed, 14 insertions(+), 1 deletions(-) [snip] diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h index b11de92..69305c6 100644 --- a/include/media/v4l2-event.h +++ b/include/media/v4l2-event.h @@ -28,6 +28,10 @@ #include linux/types.h #include linux/videodev2.h +#include asm/atomic.h + +#define V4L2_MAX_EVENTS 1024 /* Ought to be enough for everyone. */ I think this should be programmable by the driver. Most drivers do not use events at all, so by default it should be 0 or perhaps it can check whether the ioctl callback structure contains the event ioctls and set it to 0 or some initial default value. And you want this to be controlled on a per-filehandle basis even. If I look at ivtv, then most of the device nodes will not have events, only a few will support events. And for one device node type I know that there will only be a single event when stopping the streaming, while another device node type will get an event each frame. Don't you mean per video node instead of per file handle ? In that case we could add a new field to video_device structure that must be initialized by drivers before registering the device. Yes, that's what I meant (although you state it much more clearly :-) ). Regards, Hans So being able to adjust the event queue dynamically will give more control and prevent unnecessary waste of memory resources. -- Regards, Laurent Pinchart -- 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: [RFC v2 0/7] V4L2 file handles and event interface
Hi Hans, On Monday 18 January 2010 14:07:33 Hans Verkuil wrote: On Tue, 22 Dec 2009, Sakari Ailus wrote: Hi, Here's the second version of the V4L2 file handle and event interface patchset. Still RFC since I'd like to get more feedback on it. The first patch adds the V4L2 file handle support and the rest are for V4L2 events. The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP are not part of this patchset but are available in Gitorious (branch is called events): git://gitorious.org/omap3camera/mainline.git event The major change since the last one v4l2_fh structure is now part of driver's own file handle. It's used as file-private_data as well. I did this based on Hans Verkuil's suggestion. Sequence numbers and event queue length limitation is there as well. There are countless of smaller changes, too. A few notes on the patches: - I don't like the locking too much. Perhaps the file handle specific lock (events-lock) could be dropped in favour of the lock for v4l2_file_handle in video_device? - Poll. The V4L2 specifiction says: When the application did not call VIDIOC_QBUF or VIDIOC_STREAMON yet the poll() function succeeds, but sets the POLLERR flag in the revents field. The current events for OMAP 3 ISP are related to streaming but not all might be in future. For example there might be some radio or DVB related events. I know for sure that we will have to be able to handle events when not streaming. E.g. events that tell when a HDMI connector was plugged in or when the EDID was read will need to arrive whether streaming is on or off. I agree with you. The V4L2 specification will then need to be changed, otherwise we won't be able to poll() for events. poll() wouldn't return immediately anymore if no buffer is queued or if the device isn't streaming. That might break existing applications (although we could argue that some of those applications are somehow broken already if they rely on such a weird feature). If we want to avoid disturbing existing applications we could still return POLLERR immediately when not streaming if no event has been subscribed to. I think this is a very reasonable approach. Regards, Hans - Sequence numbers are local to file handles. That is how it should be. - Subscribing V4L2_EVENT_ALL causes any other events to be unsubscribed. - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would be difficult to work around since this would require the event system to be aware of the driver private events as well. Good point. Perhaps attempting to unsubscribe a single event when EVENT_ALL has been subscribed should result in an error? I.e., you can only unsubscribe ALL when you subscribed to ALL in the first place. -- Regards, Laurent Pinchart -- 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
newbie using TechniSat SkyStar HD2
Hello, I just started with satellite TV and purchased a TechniSat SkyStar HD2 (not a brilliant start, I agree). I installed the mantis driver from http://linuxtv.org/hg/v4l-dvb as explained on the wiki. It somehow seems to work, dmesg shows: [ 3116.783103] Mantis :05:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 3116.784165] DVB: registering new adapter (Mantis DVB adapter) [ 3117.652286] stb0899_attach: Attaching STB0899 [ 3117.652298] stb6100_attach: Attaching STB6100 [ 3117.652515] LNBx2x attached on addr=8 [ 3117.652522] DVB: registering adapter 0 frontend 0 (STB0899 Multistandard)... However, when I run femon in order to get the signal level (so I can tune the antenna), I get: Problem retrieving frontend information: Operation not supported status S | signal 7f98 | snr | ber d3b53000 | unc | If I use the -H flag it shows signal level 49% which is not right because the card is not even connected to the antenna. Also dvbscan gives an error that it cannot tune to the required frequency (or something like that). As I said, the card is not yet connected to the antenna but I tried connecting it to a standalone LNB (which I imagine is the same as connecting to a not tuned antenna). Any hints? Thanks, nicolae -- 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: em28xx driver - xc3028 tuner - readreg error
2010/1/18 Devin Heitmueller dheitmuel...@kernellabs.com: On Mon, Jan 18, 2010 at 10:01 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Hi all, I am still having problem using v4l-dvb drivers with Terratec Cinergy T USB XS. As reported in first mail, I am using the last version of v4l-dvb drivers with few lines adjustment in order to make this driver to enable dvb for my dvb only device (this because official v4l-dvb driver actually doesn't support my device at all) I have cleaned my distro (openSuse 11.2 x86-64) about all the v4l modules provided by distro's repositories, and I compiled modified v4l-dvb source. So acutally I am using a cleaned version of v4l-dvb. But the [ 1483.314420] zl10353_read_register: readreg error (reg=127, ret==-19) [ 1483.315166] mt352_read_register: readreg error (reg=127, ret==-19) error isn't solved yet. Could it be related to the firmware I am using? No, this has nothing to do with firmware. It is probably an issue where the gpio configuration is wrong and the demod is being held in reset (hence it won't respond to i2c commands). The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Hi Devin, maybe it could be useful: today, without any change from yesterday, the device has been fully initialized at boot time. From dmesg 10.252753] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 10.286264] xc2028 2-0061: Loading firmware for type=BASE (1), id . [ 11.674270] xc2028 2-0061: Loading firmware for type=(0), id b700. [ 11.701412] SCODE (2000), id b700: [ 11.701419] xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. [ 11.824268] em28xx #0: v4l2 driver version 0.1.2 [ 11.829157] em28xx #0: V4L2 video device registered as video1 [ 11.830312] usbcore: registered new interface driver em28xx [ 11.830316] em28xx driver loaded [ 11.997659] xc2028 2-0061: attaching existing instance [ 11.997665] xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner [ 11.997667] em28xx #0: em28xx #0/2: xc3028 attached [ 11.997671] DVB: registering new adapter (em28xx #0) [ 11.997675] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [ 11.998086] em28xx #0: Successfully loaded em28xx-dvb [ 11.998090] Em28xx: Initialized (Em28xx dvb Extension) extension instead of (from /var/log/messages) Jan 18 16:53:04 gandalf kernel: [ 4894.539028] xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 Jan 18 16:53:04 gandalf kernel: [ 4894.575016] xc2028 2-0061: Loading firmware for type=BASE (1), id . Jan 18 16:53:05 gandalf kernel: [ 4895.972018] xc2028 2-0061: Loading firmware for type=(0), id b700. Jan 18 16:53:05 gandalf kernel: [ 4895.998010] SCODE (2000), id b700: Jan 18 16:53:05 gandalf kernel: [ 4895.998022] xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. Jan 18 16:53:05 gandalf kernel: [ 4896.122024] em28xx #0: v4l2 driver version 0.1.2 Jan 18 16:53:05 gandalf kernel: [ 4896.127126] em28xx #0: V4L2 video device registered as video1 Jan 18 16:53:05 gandalf kernel: [ 4896.129142] usbcore: registered new interface driver em28xx Jan 18 16:53:05 gandalf kernel: [ 4896.129157] em28xx driver loaded Jan 18 16:53:05 gandalf kernel: [ 4896.155171] zl10353_read_register: readreg error (reg=127, ret==-19) Jan 18 16:53:05 gandalf kernel: [ 4896.155914] mt352_read_register: readreg error (reg=127, ret==-19) Jan 18 16:53:05 gandalf kernel: [ 4896.156419] em28xx #0: /2: dvb frontend not attached. Can't attach xc3028 Jan 18 16:53:05 gandalf kernel: [ 4896.156434] Em28xx: Initialized (Em28xx dvb Extension) extension Is there a reason of this behaviour? Valerio -- 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: [ANNOUNCE] git tree repositories
Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. I know you'll continue to receive alot of thank you and great job comments from some of the developers who have been pushing for this, so I'll be the bad guy and point out the downsides to what you are proposing. First off, I would like to note that I have absolutely no problem with git. I think it's a great tool and I use it for other projects. If the question today was which source control software to use, I have no doubt I would choose git over mercurial. I've used a variety of different source control systems both open source and commercial, and git is a really good tool. That said, my real problem is with the change requiring all the active developers to be developing on the latest Linux kernel. Before I renew my arguments, I will openly acknowledge that your approach does make numerous things easier. I have little doubt that it will make merging easier for you personally, as well as addresses issues with patches that have architecture specific changes (or other changes that are outside of the current v4l-dvb tree). So let's talk about why this is bad I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). Like most smart developers, I want to have a *controlled* environment where I can be confident that if a problem arises that it's *my* changes at fault. Any time that I spend trying to figure out why my PC doesn't work is time that I'm not debugging v4l-dvb drivers. And *THAT* is why it's critical that the mainline not be treated as alpha quality like you suggested last week. For example, when you check in alpha code that causes an OOPS whenever any tuner with IR support is plugged in, I waste several hours debugging the regression you introduced instead of doing my own work. Further, we're also changing from a system where we build a relatively small tree of modules to one where we're going to be building/installing entire kernels. Even on my relatively recent hardware, this is process that takes upwards to an hour (and yes, I do have ccache). Even a make modules_install can several minutes. So now I'm going from being able to make make install make unload twenty times an hour to a *MUCH* slower process. We're giving up the ability to have a fast debug-compile-test cycle for developers in exchange for easier merging of the final result. This seems like a poor optimization choice for those of us who spend all day compiling, debugging, and testing. Personally, I spend about 98% of my time actively debugging code, and about 2% of my time dealing with merge issues. So I *really* care about things like how long it takes to compile and install the tree. I hope other developers will offer their opinions on this approach, since it's all of us who will pay the price in time as a result of this change. If all the developers who are writing the code think it's a good idea to be half as efficient in order to make the merging easier for one person, then so be it. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. 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 Win TV HVR-1300: streaming and grabbing fail after a while, changing resolution renders card inoperable
I'm sorry, two of the problems described in my mail have nothing to do with the driver. There's a daemon running that accesses the tuner and vbi (nxtvepg), which causes problems 1 and 2. I've failed to notice this because nxtvepg can (normally) detect tvtime and xawtv and doesn't interfere with them, so I assumed it might have a general mechanism for detecting if the tv driver is in use by a different app. The third problem remains: Friedel wrote: 3) changing resolutions causes mpeg encoder stream to become completely inoperable When I switch resolutions in mythtv recording profile, but also via e.g. v4l2-ctl -d /dev/video1 --set-fmt-video=width=720,height=568 I seem to totally break the encoder. There's no stream any more, ~ cat /dev/video1 cat: /dev/video1: Input/output error And switching the resolution back doesn't help. Unloading the modules doesn't help either, I have to reboot the box. dmesg output pastebinned at http://pastebin.com/f4e27757a Tests were done with a 2.6.32 kernel from ubuntu. Which I assume is a vanilla kernel. I might be wrong about this, too. I could test with newer drivers or a newer kernel of course, if you suspect that the problem might not be fixed yet. Please ask if there's any information you can't easily infer from this mail or the attached logs. -- Friedrich Delgado Friedrichs frie...@nomaden.org TauPan on Ircnet and Freenode ;) pgpp5FqgTNyRX.pgp Description: PGP signature
Re: [ANNOUNCE] git tree repositories
Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: Hi, Due to that, I'm delegating the task of keeping -hg in sync with upstream and backporting patches to run on older kernels to another person: Douglas has offered his help to keep the tree synchronized with the -git tree, and to add backport support. He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! Anytime! I do have one proposal: parts of our hg tree are independent of git: v4l2-apps, possibly some firmware build code (not 100% sure of that), v4l_experimental, perhaps some documentation stuff. My proposal is that we make a separate hg or git tree for those. It will make it easier to package by distros and it makes it easier to maintain v4l2-apps et al as well. It might even simplify Douglas's work by moving non-essential code out of the compat hg tree. It may make sense, but I have some comments about it: 1) v4l_experimental - I think we may just drop it. It was meant to be a staging area in the old days, but never worked. The 3 drivers there never suffered any maintanership. Even the firewire driver that used to be there were developed independently. So, IMO, we can just remove it and, if anyone needs those drivers, they can just look inside the -hg history. 2) firmware - the code there is just what we have in kernel. While this can be broken, I can't see much sense, as I don't foresee any changes there: new firmwares are going to linux-firmware tree and have an upstream maintainership in separate; 3) media docs - the docs are part of upstream tree. So, it doesn't make sense to have a separate tree for it. IMO, the proper direction is to merge upstream the capability of automatic generation of some xml scripts (like videobuf2.h.xml). Yet, there are a few files present on v4l2-apps that are also converted to xml, as they are usage examples at the API. I'm not sure what to do with them. 4) v4l2-apps - I agree that splitting it could be a good idea, provided that we find a way to handle the few cases where we have example applications at the media docs. I'll be updating my daily build scripts to start using git soon (I'll keep using hg for the older kernels of course). That's good! I always check if the -git compiles with x86_64, but I generally don't check all architectures on my checks. 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
Re: [ANNOUNCE] git tree repositories
Laurent Pinchart wrote: Hi Mauro, I would like to personally thank you for spending time on git support at linuxtv.org. Git support was a long-awaited feature for many developers (and I certainly was one of them). All the work done behind the scene on linuxtv.org isn't seen by end-users and can thus be less rewarding than working on the code. However, it's of critical importance to make the development process as smooth as possible. For that reason, thank you again. You're welcome! Working at the infrastructure spends lots of time and, as you said, people generally only note when there's something broken. I'm quite confident that supporting -git is the proper path to make life easier for contributors and developers and opening a new road to the future of the subsystem. 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
Re: [ANNOUNCE] git tree repositories
On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Most linux developers will have a clone of Linus' tree already, and you can add as many remotes to that tree as you like. It's much faster and more flexible that way. If you once pulled a clone of Linus' tree there is simply no need to ever clone any other Linux tree ever again. Oh, and if you manage to get your git tree in a state where you don't know how to fix the mess, don't throw it away. Go to the git mailing list and ask for advice. They love customer feeedback. Helps them to improve their product and make it more user friendly ;-) Johannes -- 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: [ANNOUNCE] git tree repositories
On Tue, 19 Jan 2010, Johannes Stezenbach wrote: On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Of course I cloned from git.kernel.org and not from linuxtv.org. Still it was my first clone of linux ever. -- Patrick Boettcher - 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: [ANNOUNCE] git tree repositories
Hi Devin, On Tue, 19 Jan 2010, Devin Heitmueller wrote: [..] I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). I agree with Devin. We can't lose and off-tree build system like we have it today in v4l-dvb. What I suggested in my first Email was to put the build system outside the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to make links from the linux-v4l-dvb/ clone. I'm not sure what needs to be done for the backward-compat with #if KERNEL_VERSION ... But I'm sure we can find a solution for that. -- Patrick Boettcher - 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: [ANNOUNCE] git tree repositories
Patrick Boettcher wrote: On Tuesday 19 January 2010 08:53:10 Hans Verkuil wrote: On Tuesday 19 January 2010 06:34:18 Mauro Carvalho Chehab wrote: He already started doing that, fixing some incompatibility troubles between some drivers and older kernels. Mauro, I just wanted to thank you for doing all the hard work in moving to git! And a big 'thank you' to Douglas as well for taking over hg maintenance! A big thank you also from me. Wou're welcome. I'm strongly in need of a build-only-v4l-dvb build system. Because I'm most of the time using distro-kernels in my productive environments and I'm replacing v4l/dvb drivers with the one from v4l-dvb. We all need to have some ways to run the new drivers on distro kernels. If not as a developer, at least as an user. So, I keep believing that the out-of-tree compilation is fundamental to the success of the subsystem. One step into the direction of a solution might be: Why not including the v4l-dvb/v4l/Makefile and the related files into that separate repository Hans is describing here and then telling 'make' to make links to ../../v4l-dvb/ instead of ../linux as of today. This is about what make kernel-links do, but in the opposite direction. It shouldn't be hard do do that, but we need to fix the backports. In the case of -alsa, they opted to use this strategy for their backported tree, patching the kernel when building it. But I don't know how to solve the ifdef KERNEL_VERSION for having backward compatibility in the source files. Maybe with a patch for each kernel version? It can be a patch for each kernel version, but this will remove support for some distro-kernels where the KABI has changed. Another solution is to have a pile of patches that will be applied as the compilation breaks. This can work, but we need to find a way to produce those patches. Maybe the simplest solution is to keep maintaining the -hg and having an auto-generated tree that will have just the building system and a diff between -git and -hg. If both are synchronized, the only difference will be the backports. BTW: I just made a clone of the git-tree - 365MB *ouff*. Yes, this is one problem with -git: as it contains the entire kernel struct, and an history since 2.6.11, it is about 9 times bigger than the -hg tree, where only the media files are stored. Yet, git clone has a way to allow removing the history of the kernel, producing a small result --depth: $ git clone --depth 1 --bare v4l-dvb tmp This gives about 128M (about 3x -hg). Yet, trees generated with --depth have some disadvantages. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Yes. The cost for a new branch is zero. Also, the cost of a new clone is less than 1M, if you use the --shared. On my daily usage, I use a lot to clone with --shared, and doing my work on independent directories. The advantage is that you avoid messing your temporary work. You may even pull or push just one branch into another tree. So, working with git offers lots of new possibilities to the developers. Cheers, Mauro. best regards, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git tree repositories
Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. 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
Re: [ANNOUNCE] git tree repositories
So am I. I hope the future will prove us right :-) :) How do your new git scripts process commits ? In particular, does the Priority: line still applies ? For patches imported from -hg, the script will handle Priority. For patches generated against -git, maybe the better is to have separate branches or trees: one for fixes and another for new stuff, and an indication, at the pull request, to what tree the patch will be applied. We still need some discussions about the process. One of the issues is how do we'll handle SOB's. My SOB should be added on all patches. Also, sometimes, patches may need to receive other SOB-like tags, like acked-by. I'm not sure yet how should we handle it, since a change at the patch description will change the hash code. -git merge is generally smart enough to not generate a conflict between two patches with identical diffs, but we need to do some tests in order to check what would be the better procedure. 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
Re: [ANNOUNCE] git tree repositories
Patrick Boettcher wrote: Hi Devin, On Tue, 19 Jan 2010, Devin Heitmueller wrote: [..] I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). I agree with Devin. We can't lose and off-tree build system like we have it today in v4l-dvb. What I suggested in my first Email was to put the build system outside the v4l-dvb into another repo (e.g. 'v4l-dvb-build') and then telling it to make links from the linux-v4l-dvb/ clone. I'm not sure what needs to be done for the backward-compat with #if KERNEL_VERSION ... But I'm sure we can find a solution for that. I started a branch with an alternative for if KERNEL_VERSION. Please see: http://linuxtv.org/hg/~mchehab/backport/ Basically, it has some perl rules that identifies the points on the source code where an KABI function has changed and dynamically patches the code. On my tests, this strategy works fine, but I haven't finished removing all KERNEL_VERSION checks from the code. If someone is interested, please be my guest fixing the code and improving it. Cheers, Mauro. -- Patrick Boettcher - 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: [ANNOUNCE] git tree repositories
Johannes Stezenbach wrote: On Tue, Jan 19, 2010 at 09:10:39AM +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Maybe it's worth to mention right now, that one big difference to HG in the way we have used it, is that one developer now can do all the work only with one clone of v4l-dvb and using branches for each development. Please note that you SHOULD NOT clone from linuxtv.org. Please follow the description on the top of http://linuxtv.org/git/ Most linux developers will have a clone of Linus' tree already, and you can add as many remotes to that tree as you like. Yes. I have here one stable tree that have one remote for every stable tree since 2.6.16. It's much faster and more flexible that way. If you once pulled a clone of Linus' tree there is simply no need to ever clone any other Linux tree ever again. Yes. I personally prefer to have a bare clone (bare trees have just the -git objects, and not a workig tree), and several working copies. I do the work at the working copies, and, after they are fine, I push into the bare and send the branches from bare to upstream. Oh, and if you manage to get your git tree in a state where you don't know how to fix the mess, don't throw it away. Go to the git mailing list and ask for advice. They love customer feeedback. Helps them to improve their product and make it more user friendly ;-) Yes. One good thing to do is to take a look at git reflog. It tracks all the changes you do, and you can always ask git to move to a different object at the tree, undoing the bad thing you did ;) Johannes -- 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: [ANNOUNCE] git tree repositories
Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? -- 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: [ANNOUNCE] git tree repositories
Laurent Pinchart wrote: Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? Push will only work if you use the ssh url. the url is basically the same of http, but replacing to ssh: ssh://linuxtv.org/git/tree On your case ssh://linuxtv.org/git/pinchartl/uvcvideo.git 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
Re: [ANNOUNCE] git tree repositories
Hi Mauro, On Tuesday 19 January 2010 14:07:39 Mauro Carvalho Chehab wrote: Laurent Pinchart wrote: Hi Mauro, I've started playing with the linuxtv git repositories. I've cloned v4l- dvb.git into git://linuxtv.org/pinchartl/uvcvideo.git using git-menu and now have trouble pushing changes: $ git push -v uvcvideo Pushing to git://linuxtv.org/pinchartl/uvcvideo.git fatal: The remote end hung up unexpectedly What URL should I use to push changes ? Push will only work if you use the ssh url. the url is basically the same of http, but replacing to ssh: ssh://linuxtv.org/git/tree On your case ssh://linuxtv.org/git/pinchartl/uvcvideo.git One step further: $ git push -v uvcvideo Pushing to ssh://linuxtv.org/git/pinchartl/uvcvideo.git Permission denied (publickey). fatal: The remote end hung up unexpectedly Do I need to upload my public key somewhere ? I already use it with hg push (and ssh git-menu) without any issue. -- Cheers, 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: DM1105: could not attach frontend 195d:1105
2010/1/19 pau...@planar.id.au: Well, as I understood, GPIO15 drives reset for demod. dm1105 driver needs little patching. Igor, Not to hassle you, I'm sure you're very busy. Is this something I could undertake myself? If so, which driver would you recommend I copy from - I saw on the list that some drivers do their own GPIO management, and others use a generic GPIO layer. I presume we'd need to use the generic layer? Also, from your explanation it sounds like we need to set GPIO 15 to true before we attempt to attach. Is that correct? From my reading there are two GPIO registers (8 bits each), so we'd be bit masking bit 7 in the second GPIO register to 1, then sending that GPIO to the card? Thanks for any tips, Paul As you can see there is two 32-bit registers. First for values, second for controls. Control means 0 for output and 1 for input. If I remember it is 17 GPIO lines only. /* GPIO Interface */ #define DM1105_GPIOVAL 0x08 #define DM1105_GPIOCTR 0x0c BR Igor -- 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
TDA18272
just wondering if there are any cards which use this? or are there any planned cards? not in the UK so don't yet need DVB-T2, but nevertheless curious -- simon -- 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/RFC v1 0/1] Buffer sync for non cache-coherent architectures
Hello,
this is the initial patch for buffer data synchronization for architectures
with non-coherent cache.
=
Rationale
=
Architectures with non-coherent CPU cache (e.g. ARM) require a sync both before
and after a hardware operation. Until now, videobuf could work properly for
cache-coherent memory areas only, which for ARM actually means no cache at all.
This is not only reduces functionality, but hinders performance.
We would like to add support for video buffers present in CPU-cached areas as
well, which is especially important for OUTPUT buffers, but valid for CAPTURE
buffers as well (see DMA_FROM_DEVICE below).
We have isolated 4 different types of sync operations. Three of them are the
ones defined in pci.h and dma-mapping.h (enum dma_data_direction):
- DMA_FROM_DEVICE - the buffer is to be used as a destination buffer, the
data contained within before the operation is unimportant.
Although the data in memory is not important, we have to prevent a possible
future writeback to it resulting in an accidental overwrite of contents
produced by hardware after an operation. This requires cache invalidation
before the operation.
- DMA_TO_DEVICE - the data in buffer has been touched by (prepared using)
the CPU and will be used as valid source for an operation. This data
may still be in cache but not yet in memory. This requires a writeback.
- DMA_BIDIRECTIONAL - the buffer will be used as both source and destination.
This requires both writeback and cache invalidation.
There is one more operation we are considering, although not really
cache-related:
- FINISH - the operation is finished and the data in buffer (put there by
hardware) will be used further.
Operations required here may include:
* Making the memory pages involved in the operation dirty.
* Copying data back from a bounce buffer.
They are not strictly cache-related, but valid from the point of view
of our proposed approach.
From the point of view of the videobuf framework, the following scenarios can
be
isolated, depending on when the sync has been called and current buffer type:
- before hardware operation
- OUTPUT: DMA_TO_DEVICE
- CAPTURE: DMA_FROM_DEVICE
- after hardware operation
- OUTPUT: nothing
- CAPTURE: FINISH
DMA_BIDIRECTIONAL would take place for OUTPUT+CAPTURE buffers, which are not
(yet?) used in videobuf.
=
sync() in videobuf
=
videobuf includes a sync operation, declared in struct videobuf_qtype_ops,
which can be implemented by each memory type-specific module. It is used for
different purposes than cache management though, namely for operations like
copying data back from bounce buffers after an operation.
Only videobuf-dma-sg does anything in its sync currently.
Operations required to be done before hardware operation is started are
currently performed in iolock(), but it is not usable for cache coherency
management. The reason for this is that iolock() is intended to be run once
per buffer, not once per each hardware operation. Cache coherency operations
have to be performed before every operation though, also on previously
iolock()ed buffers.
We believe that the existing videobuf sync() operation can be extended for cache
management. This requires adding sync() calls before each hardware operation
as well. It is left to the callee to determine the kind of sync requested,
taking into account the guidelines below.
No new flags/states/etc. have to be added to videobuf for it to support all
kinds of syncs mentioned above. Current sync type can be determined in
memory-specific code in two steps:
1. CAPTURE or OUTPUT - based on buffer type in struct videobuf_queue.
2. before or after operation - based on buffer state in struct videobuf_buffer:
VIDEOBUF_DONE or VIDEOBUF_ERROR - after, otherwise - before.
Example (pseudo)code for a sync() operation:
#define is_sync_after(vb) \
(vb-state == VIDEOBUF_DONE || vb-state == VIDEOBUF_ERROR)
int videobuf_foo_sync(struct videobuf_queue *q, struct videobuf_buffer *vb)
{
/* ... */
if (is_sync_after(vb) {
/* Sync after operation */
if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
do_sync_finish();
} else if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* nothing, unless we are missing something */
}
} else {
/* Sync before operation */
if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
do_sync_from_device();
} else if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
do_sync_to_device();
}
}
/* ... */
}
=
About this patch
=
This is a very small patch, just a starting point for future, memory-specific
development. No existing functionality is changed. These are the only changes
that - in our opinion - are required in the core framework. Each memory-specific
videobuf submodule will
[PATCH v1 1/1] V4L: Add sync before a hardware operation to videobuf.
Architectures with non-coherent CPU cache (e.g. ARM) may require a cache
flush or invalidation before starting a hardware operation if the data in
a video buffer being queued has been touched by the CPU.
This patch adds calls to sync before a hardware operation that are expected
to be interpreted and handled by each memory type-specific module.
Whether it is a sync before or after the operation can be determined from
the current buffer state: VIDEOBUF_DONE and VIDEOBUF_ERROR indicate a sync
called after an operation.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c |9 +
drivers/media/video/videobuf-dma-sg.c |6 ++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index bb0a1c8..e56c67a 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -561,6 +561,8 @@ int videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
+ CALL(q, sync, q, buf);
+
list_add_tail(buf-stream, q-stream);
if (q-streaming) {
spin_lock_irqsave(q-irqlock, flags);
@@ -761,6 +763,8 @@ static ssize_t videobuf_read_zerocopy(struct videobuf_queue
*q,
if (0 != retval)
goto done;
+ CALL(q, sync, q, q-read_buf);
+
/* start capture wait */
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
@@ -826,6 +830,8 @@ ssize_t videobuf_read_one(struct videobuf_queue *q,
goto done;
}
+ CALL(q, sync, q, q-read_buf);
+
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
spin_unlock_irqrestore(q-irqlock, flags);
@@ -893,6 +899,9 @@ static int __videobuf_read_start(struct videobuf_queue *q)
err = q-ops-buf_prepare(q, q-bufs[i], field);
if (err)
return err;
+
+ CALL(q, sync, q, q-read_buf);
+
list_add_tail(q-bufs[i]-stream, q-stream);
}
spin_lock_irqsave(q-irqlock, flags);
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index fa78555..2b153f8 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -50,6 +50,9 @@ MODULE_LICENSE(GPL);
#define dprintk(level, fmt, arg...)if (debug = level) \
printk(KERN_DEBUG vbuf-sg: fmt , ## arg)
+#define is_sync_after(vb) \
+ (vb-state == VIDEOBUF_DONE || vb-state == VIDEOBUF_ERROR)
+
/* - */
struct scatterlist*
@@ -516,6 +519,9 @@ static int __videobuf_sync(struct videobuf_queue *q,
BUG_ON(!mem);
MAGIC_CHECK(mem-magic,MAGIC_SG_MEM);
+ if (!is_sync_after(buf))
+ return 0;
+
return videobuf_dma_sync(q,mem-dma);
}
--
1.6.4.2.253.g0b1fac
--
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: RE: How to use saa7134 gpio via gpio-sysfs?
On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de wrote: Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann Hello Hermann, good to hear from you again. It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574 module that was used for digital I/O earlier was no longer available and something I read lead me to believe I should use gpio-sysfs instead. I'm sorry for the noise. - Gordon -- 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: omap34xxcam question?
Michael Trimarchi wrote: Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:39 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 11:25 AM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: omap34xxcam question? Hi, Aguirre, Sergio wrote: -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Thursday, January 14, 2010 6:01 AM To: linux-media@vger.kernel.org Cc: Aguirre, Sergio Subject: omap34xxcam question? Hi Is ok that it try only the first format and size? why does it not continue and find a matching? Actually, that was the intention, but I guess it was badly implemented. Thanks for the catch, and the contribution! Regards, Sergio @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; Is the patch good? or you are going to provide a better fix Yes. Sorry if I wasn't clear enough. Looks good to me, and I don't have a better fix on top of my head for the moment... I'm assuming you tested it in your environment, right? Ok, my enviroment is not pretty stable but for sure this is required. There is one problem: Suppose that the camera support this format: YUV and RAW10 The video4linux enumeration is done in this order. We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory) but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi configuration first. Hope that is clear. Hmm.. I see. So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam index 53b587e..75bd858 100644 --- a/drivers/media/video/omap34xxcam.c +++ b/drivers/media/video/omap34xxcam.c @@ -448,6 +448,10 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, break; dev_dbg(vdev-vfd-dev, trying fmt %8.8x (%d)\n, fmtd.pixelformat, fmtd_index); + + if (fmtd.pixelformat != best_pix_in-pixelformat) + continue; + /* * Get supported resolutions. */ @@ -470,7 +474,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev, pix_tmp_out = *wanted_pix_out; rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out); if (rval) - return rval; + continue; dev_dbg(vdev-vfd-dev, this w %d\th %d\tfmt %8.8x\t Somenthing like that. michael Michael Regards, Sergio Michael If yes, then I'll take the patch in my queue for submission to Sakari's tree. Thanks for your time. Regards, Sergio Michael Michael -- 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 -- 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 -- 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] Support for LT168G sensor on t613 webcam driver
Patch to support this sensor, with id code 0x0802, on the t613
driver. I just sniffed the values from the driver that came with mine,
and made the proper extensions to the original code.
Signed-off-by: Nicolau Werneck nwern...@gmail.com
diff -Nru gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c
gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c
--- gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c 2009-12-30
02:53:07.0 -0500
+++ gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c
2009-12-30 10:52:47.0 -0500
@@ -52,6 +52,7 @@
#define SENSOR_OM6802 0
#define SENSOR_OTHER 1
#define SENSOR_TAS5130A 2
+#define SENSOR_LT168G 3 /* must verify if this is the actual model */
};
/* V4L2 controls supported by the driver */
@@ -306,6 +307,17 @@
0xbe, 0x36, 0xbf, 0xff, 0xc2, 0x88, 0xc5, 0xc8,
0xc6, 0xda
};
+static const u8 n4_lt168g[] = {
+ 0x66, 0x01, 0x7f, 0x00, 0x80, 0x7c, 0x81, 0x28,
+ 0x83, 0x44, 0x84, 0x20, 0x86, 0x20, 0x8a, 0x70,
+ 0x8b, 0x58, 0x8c, 0x88, 0x8d, 0xa0, 0x8e, 0xb3,
+ 0x8f, 0x24, 0xa1, 0xb0, 0xa2, 0x38, 0xa5, 0x20,
+ 0xa6, 0x4a, 0xa8, 0xe8, 0xaf, 0x38, 0xb0, 0x68,
+ 0xb1, 0x44, 0xb2, 0x88, 0xbb, 0x86, 0xbd, 0x40,
+ 0xbe, 0x26, 0xc1, 0x05, 0xc2, 0x88, 0xc5, 0xc0,
+ 0xda, 0x8e, 0xdb, 0xca, 0xdc, 0xa8, 0xdd, 0x8c,
+ 0xde, 0x44, 0xdf, 0x0c, 0xe9, 0x80
+};
static const struct additional_sensor_data sensor_data[] = {
{ /* 0: OM6802 */
@@ -422,6 +434,23 @@
.stream =
{0x0b, 0x04, 0x0a, 0x40},
},
+{ /* 3: LT168G */
+ .n3 = {0x61, 0xc2, 0x65, 0x68, 0x60, 0x00},
+ .n4 = n4_lt168g,
+ .n4sz = sizeof n4_lt168g,
+ .reg80 = 0x7c,
+ .reg8e = 0xb3,
+ .nset8 = {0xa8, 0xf0, 0xc6, 0xba, 0xc0, 0x00},
+ .data1 = {0xc0, 0x38, 0x08, 0x10, 0xc0, 0x30, 0x10, 0x40,
+0xb0, 0xf4},
+ .data2 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+0xff},
+ .data3 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+0xff},
+ .data4 = {0x66, 0x41, 0xa8, 0xf0},
+ .data5 = {0x0c, 0x03, 0xab, 0x4b, 0x81, 0x2b},
+ .stream = {0x0b, 0x04, 0x0a, 0x28},
+},
};
#define MAX_EFFECTS 7
@@ -758,6 +787,10 @@
PDEBUG(D_PROBE, sensor tas5130a);
sd-sensor = SENSOR_TAS5130A;
break;
+ case 0x0802:
+ PDEBUG(D_PROBE, sensor lt168g);
+ sd-sensor = SENSOR_LT168G;
+ break;
case 0x0803:
PDEBUG(D_PROBE, sensor 'other');
sd-sensor = SENSOR_OTHER;
@@ -800,6 +833,13 @@
reg_w_buf(gspca_dev, sensor-n3, sizeof sensor-n3);
reg_w_buf(gspca_dev, sensor-n4, sensor-n4sz);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -824,6 +864,13 @@
reg_w_buf(gspca_dev, sensor-nset8, sizeof sensor-nset8);
reg_w_buf(gspca_dev, sensor-stream, sizeof sensor-stream);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -930,6 +977,8 @@
case SENSOR_OM6802:
om6802_sensor_init(gspca_dev);
break;
+ case SENSOR_LT168G:
+ break;
case SENSOR_OTHER:
break;
default:
--
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 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: 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:Tue Jan 19 19:00:04 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14011:c3cc688bde82 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: WARNINGS linux-2.6.33-rc2-armv5-davinci: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-armv5-ixp: WARNINGS linux-2.6.33-rc2-armv5-ixp: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: WARNINGS linux-2.6.32-armv5-omap2: WARNINGS linux-2.6.33-rc2-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: WARNINGS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-mips: WARNINGS linux-2.6.33-rc2-mips: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: RE: How to use saa7134 gpio via gpio-sysfs?
Hello Gordon, Am Dienstag, den 19.01.2010, 10:24 -0700 schrieb Gordon Smith: On Mon, Jan 18, 2010 at 5:01 PM, hermann pitton hermann-pit...@arcor.de wrote: Hello, Am Montag, den 18.01.2010, 18:11 -0500 schrieb Will Tate: I'm not sure why access in userspace would be required. I checked the schematic today and all the GPIO pins are used to communicate with the SAA6752HS on board for compression. We do not bring the GPIO off the board anywhere. thank you very much. I was still expecting that and did not get Gordon's point, but must admit to have been totally unaware about the DI/O features. RTD did all the hardware implementations themselves. Very nice job that time. Gordon and I have spoken previously about the RTD software for digital I/O breaking with the migration of pcf8574 driver to the pcf857x. So, perhaps he intended to use GPIO until I can fix the digital I/O software. Ah, good to know. BTW, we had the mpeg encoder broken unnoticed for some kernels, but due to fixes by Dmitri Belimov and extensions by Hans Verkuil, we are much better on it these days. Enjoy. Always let us know, if we can do anything or at least make it public for those interested to work on it. Thanks, Hermann Hello Hermann, good to hear from you again. It looks like I was off track regarding GPIO. In 2.6.30 the pcf8574 module that was used for digital I/O earlier was no longer available and something I read lead me to believe I should use gpio-sysfs instead. I'm sorry for the noise. - Gordon no problem at all. It was quite interesting to think about such gpio use. If such a card appears in the future, we can point to the thread you started here and have already, thanks to Trent, a collection of good ideas and comments. Cheers, Hermann -- 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: [ANNOUNCE] git tree repositories
On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote: Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. Cheers, Mauro. I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates. However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers. My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories. Am I correct to believe my process will not be affected by the shift to git? That is, will existing kernels will still have access to the current v4l code via hg? I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it). Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel? Lurker testers and wannabe developers need to know! -BobC -- 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: [ANNOUNCE] git tree repositories
Hi, may I humbly request to make it mandatory to enter a description when a user creates a new tree on linuxtv.org? IMHO foobar development repository isn't useful at all. If I look at http://linuxtv.org/hg/ many times I have no clue what a repo is about or why it exists at all. Let's not repeat the same mistake with git. OTOH, since with git it is common to have multiple branches within one repository, I'm not sure how it works. It would be cool if git would support per-branch descriptions, and git web could display them. Johannes -- 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: [ANNOUNCE] git tree repositories
Hi Bob, Am Dienstag, den 19.01.2010, 13:21 -0800 schrieb Bob Cunningham: On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote: Devin Heitmueller wrote: Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. The announcement by purpose doesn't contain any changes on the process, since it requires some discussions before we go there. It is just the first step, where -git tree support were created. It also announces that I personally won't keep maintaining -hg, delegating its task to Douglas. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. I fully understand that supporting the development and tests with an out of tree building is important to everybody. So, the plans are to keep the out-of-tree building system maintained, and even improving it. I'd like to thank to Douglas for his help on making this happen. Cheers, Mauro. I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates. However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers. My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories. Am I correct to believe my process will not be affected by the shift to git? That is, will existing kernels will still have access to the current v4l code via hg? I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it). Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel? Lurker testers and wannabe developers need to know! -BobC if you look at the history of v4l, you can be sure that we always tried to have as much testers as possible. During the 2.5.x development cycle, in fact all testing and development was done on 2.4.x. We did not even have any SCM that time, but on 2.5.x problems Devin is pointing to were enormous. Mike Krufky and Mauro were always strong in defending backward compat, also after taking over Gerd's cvs he later had. Mauro, in the beginning, even always tried to keep usability back to 2.4.x kernels with v4l2 revision 1 and I did warn him, that this task is quite impossible to satisfy, but we had developers on totally outdated semi proprietary stuff, years in delay, asking exactly for that. On latest discussions, how far we should keep backward compat after i2c improvements, you saw Mauro again voting for as far as ever possible. Be sure, we don't want to lose you guys! Cheers, Hermann -- 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] V4L/DVB: [Mantis] remove duplicated #include
Remove duplicated #include('s) in
drivers/media/dvb/mantis/mantis_hif.c
drivers/media/dvb/mantis/mantis_pci.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/media/dvb/mantis/mantis_hif.c |2 --
drivers/media/dvb/mantis/mantis_pci.c |5 -
2 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/mantis/mantis_hif.c
b/drivers/media/dvb/mantis/mantis_hif.c
index 7477dac..5772ebb 100644
--- a/drivers/media/dvb/mantis/mantis_hif.c
+++ b/drivers/media/dvb/mantis/mantis_hif.c
@@ -22,8 +22,6 @@
#include linux/signal.h
#include linux/sched.h
-#include linux/signal.h
-#include linux/sched.h
#include linux/interrupt.h
#include dmxdev.h
diff --git a/drivers/media/dvb/mantis/mantis_pci.c
b/drivers/media/dvb/mantis/mantis_pci.c
index 6c7534a..59feeb8 100644
--- a/drivers/media/dvb/mantis/mantis_pci.c
+++ b/drivers/media/dvb/mantis/mantis_pci.c
@@ -41,11 +41,6 @@
#include dvb_frontend.h
#include dvb_net.h
-#include asm/irq.h
-#include linux/signal.h
-#include linux/sched.h
-#include linux/interrupt.h
-
#include mantis_common.h
#include mantis_reg.h
#include mantis_pci.h
--
1.6.1.3
--
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: [ANNOUNCE] git tree repositories
On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints
Hi,
Looks good to me now.
Regards,
Hans
On 01/18/2010 09:01 PM, Németh Márton wrote:
From: Márton Némethnm...@freemail.hu
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Mon Jan 18 20:43:55 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Némethnm...@freemail.hu
+ *
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
@@ -41,6 +44,9 @@
#include gspca.h
+#includelinux/input.h
+#includelinux/usb/input.h
+
/* global values */
#define DEF_NURBS 3 /* default number of URBs */
#if DEF_NURBS MAX_NURBS
@@ -112,6 +118,186 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+ int ret;
+
+ ret = urb-status;
+ switch (ret) {
+ case 0:
+ if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+ urb-transfer_buffer, urb-actual_length) 0) {
+ PDEBUG(D_ERR, Unknown packet received);
+ }
+ break;
+
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ENODEV:
+ case -ESHUTDOWN:
+ /* Stop is requested either by software or hardware is gone,
+* keep the ret value non-zero and don't resubmit later.
+*/
+ break;
+
+ default:
+ PDEBUG(D_ERR, URB error %i, resubmitting, urb-status);
+ urb-status = 0;
+ ret = 0;
+ }
+
+ if (ret == 0) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret 0)
+ PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+ }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev-input_dev = NULL;
+ if (dev-sd_desc-int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+ strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+ input_dev-name = dev-sd_desc-name;
+ input_dev-phys = dev-phys;
+
+ usb_to_input_id(dev-dev,input_dev-id);
+
+ input_dev-evbit[0] = BIT_MASK(EV_KEY);
+ input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev-dev.parent =dev-dev-dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, Input device registration failed
+ with error %i, err);
+ input_dev-dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev-input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep-wMaxPacketSize;
+ interval = ep-bInterval;
+ PDEBUG(D_PROBE, found int in endpoint: 0x%x,
+ buffer_len=%u, interval=%u,
+ ep-bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev-dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize,
+ GFP_KERNEL,urb-transfer_dma);
+ if (!buffer) {
+ ret = -ENOMEM;
+ goto error_buffer;
+ }
+ usb_fill_int_urb(urb, dev,
+ usb_rcvintpipe(dev, ep-bEndpointAddress),
+ buffer, buffer_len,
+ int_irq, (void *)gspca_dev, interval);
+ gspca_dev-int_urb = urb;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret 0) {
+ PDEBUG(D_ERR, submit URB failed with error
[PATCH] cx23885: Wrong command printed in cmd_to_str()
The wrong command was printed for case CX2341X_ENC_SET_DNR_FILTER_MODE, and a typo in case CX2341X_ENC_SET_PCR_ID. Signed-off-by: Roel Kluin roel.kl...@gmail.com --- Or is this intended? diff --git a/drivers/media/video/cx23885/cx23885-417.c b/drivers/media/video/cx23885/cx23885-417.c index 88c0d24..2ab97ad 100644 --- a/drivers/media/video/cx23885/cx23885-417.c +++ b/drivers/media/video/cx23885/cx23885-417.c @@ -681,7 +681,7 @@ static char *cmd_to_str(int cmd) case CX2341X_ENC_SET_VIDEO_ID: return SET_VIDEO_ID; case CX2341X_ENC_SET_PCR_ID: - return SET_PCR_PID; + return SET_PCR_ID; case CX2341X_ENC_SET_FRAME_RATE: return SET_FRAME_RATE; case CX2341X_ENC_SET_FRAME_SIZE: @@ -693,7 +693,7 @@ static char *cmd_to_str(int cmd) case CX2341X_ENC_SET_ASPECT_RATIO: return SET_ASPECT_RATIO; case CX2341X_ENC_SET_DNR_FILTER_MODE: - return SET_DNR_FILTER_PROPS; + return SET_DNR_FILTER_MODE; case CX2341X_ENC_SET_DNR_FILTER_PROPS: return SET_DNR_FILTER_PROPS; case CX2341X_ENC_SET_CORING_LEVELS: -- 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: [ANNOUNCE] git tree repositories
Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy Hi Andy, :) please take it only as that. What about assuming a 1800 kbps low level flat rate and all phone calls for free, except for some exotic ;) mobile net providers, for the whole family, including a mobile flat, 4 different phone numbers, video on demand, and much more you don't need, for 30€ per months? It is always said, we are so much in delay with such here, but seeing the above calculation, it is ten years back paying for nothing the triple money and wait for a day. And preferably the phone of course is blocked during that. You are living in the USA? Seems sending CDs per express air mail is much cheaper ..., even using Brazil as a relay ;) Are you sure, you did not miss to update your provider ten years back the first time? We have local traffic since years, leaving Germany in the north, coming in over there through Canada, crossing the whole States, and coming back from Florida to arrive a few miles away from me, just because of unused backbones. Also VOIP calls are quite fine these days, but local thunderstorms in between are still often a disaster for hours in summer. Taking the smileys out now, in fact distributions have Gigas of updates within a few weeks these days. Andy for sure has an argument. Cheers, Hermann -- 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] mxl5005s: bad checks of state-Mode
Regardless of the state-Mode in both cases the same value was
written.
If state-Mode wasn't set, it is always 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/media/common/tuners/mxl5005s.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
Or were the ones and zeroes in these MXL_ControlWrite in the wrong place?
diff --git a/drivers/media/common/tuners/mxl5005s.c
b/drivers/media/common/tuners/mxl5005s.c
index 605e28b..3967412 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -1815,9 +1815,8 @@ static u16 MXL_BlockInit(struct dvb_frontend *fe)
/* Charge Pump Control Dig Ana */
status += MXL_ControlWrite(fe, RFSYN_CHP_GAIN, state-Mode ? 5 : 8);
- status += MXL_ControlWrite(fe,
- RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1);
- status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0);
+ status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, 1);
+ status += MXL_ControlWrite(fe, EN_CHP_LIN_B, 0);
/* AGC TOP Control */
if (state-AGC_Mode == 0) /* Dual AGC */ {
@@ -2161,7 +2160,7 @@ static u16 MXL_IFSynthInit(struct dvb_frontend *fe)
}
}
- if (state-Mode || (state-Mode == 0 state-IF_Mode == 0)) {
+ if (state-Mode || state-IF_Mode == 0) {
if (state-IF_LO == 5700UL) {
status += MXL_ControlWrite(fe, IF_DIVVAL, 0x10);
status += MXL_ControlWrite(fe, IF_VCO_BIAS, 0x08);
--
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] mxl5005s: bad checks of state-Mode
On Tue, Jan 19, 2010 at 9:20 PM, Roel Kluin roel.kl...@gmail.com wrote:
Regardless of the state-Mode in both cases the same value was
written.
If state-Mode wasn't set, it is always 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/media/common/tuners/mxl5005s.c | 7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
Or were the ones and zeroes in these MXL_ControlWrite in the wrong place?
diff --git a/drivers/media/common/tuners/mxl5005s.c
b/drivers/media/common/tuners/mxl5005s.c
index 605e28b..3967412 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -1815,9 +1815,8 @@ static u16 MXL_BlockInit(struct dvb_frontend *fe)
/* Charge Pump Control Dig Ana */
status += MXL_ControlWrite(fe, RFSYN_CHP_GAIN, state-Mode ? 5 : 8);
- status += MXL_ControlWrite(fe,
- RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1);
- status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0);
+ status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, 1);
+ status += MXL_ControlWrite(fe, EN_CHP_LIN_B, 0);
/* AGC TOP Control */
if (state-AGC_Mode == 0) /* Dual AGC */ {
@@ -2161,7 +2160,7 @@ static u16 MXL_IFSynthInit(struct dvb_frontend *fe)
}
}
- if (state-Mode || (state-Mode == 0 state-IF_Mode == 0)) {
+ if (state-Mode || state-IF_Mode == 0) {
if (state-IF_LO == 5700UL) {
status += MXL_ControlWrite(fe, IF_DIVVAL, 0x10);
status += MXL_ControlWrite(fe, IF_VCO_BIAS, 0x08);
Roel,
Thanks for pointing this out.
This patch should not be applied.
While I agree with Roel's assessment that the logic is incorrect,
removing the conditional logic and forcing the register writes to the
given value is almost certainly the incorrect fix. I will have to
look at the datasheet and see what the logic is actually supposed to
be.
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: [ANNOUNCE] git tree repositories
Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours It is an one time download, since, once you got it, the updates are cheap. Btw, it is a way small than a single CD needed for you to install Linux. If you want to get it and you're not willing to pay to a decent Internet connection, just ask someone to get it for you and save on a CD. Of course you can also keep using -hg. 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
Re: [ANNOUNCE] git tree repositories
On Wed, 2010-01-20 at 02:10 +0100, hermann pitton wrote: Am Dienstag, den 19.01.2010, 18:38 -0500 schrieb Andy Walls: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours :( Can git resume aborted clones? It could be many weeks before I have a 20 hour window where I don't have to use my land line phone for voice... Regards, Andy Hi Andy, :) please take it only as that. :) What about assuming a 1800 kbps low level flat rate and all phone calls for free, except for some exotic ;) mobile net providers, for the whole family, including a mobile flat, 4 different phone numbers, video on demand, and much more you don't need, for 30€ per months? It is always said, we are so much in delay with such here, but seeing the above calculation, it is ten years back paying for nothing the triple money and wait for a day. And preferably the phone of course is blocked during that. Yes, I realize I am in the dark ages. I haven't been able to build a cost case for my normal home communications needs to pay for Cable or Satellite internet service. I really dislike monthly recurring household costs for services that bill me whether I use them or not, like communications. I try to pay only for plans that meet my common usage needs and no more. My oldest child is to the point where she will need to start using the internet for research for school next year. I'll have to open my wallet soon, as my household communications needs are growing. You are living in the USA? Seems sending CDs per express air mail is much cheaper ..., even using Brazil as a relay ;) You beat me to that joke. Although I was going to say New Zealand... Are you sure, you did not miss to update your provider ten years back the first time? I live in a very rural area: No fiber optic, no DSL, EV-DO requires directional antenna and amplifier. Cable TV internet is available, but is unreliable and expensive. Satellite internet is available, of course. Regards, Andy Taking the smileys out now, in fact distributions have Gigas of updates within a few weeks these days. Andy for sure has an argument. Cheers, Hermann -- 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: [ANNOUNCE] git tree repositories
On Wed, 2010-01-20 at 01:29 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Tue, 2010-01-19 at 09:10 +0100, Patrick Boettcher wrote: BTW: I just made a clone of the git-tree - 365MB *ouff*. Assuming 53.333 kbps download speed, 0% overhead, no compression: 365 MiB * 2^20 bytes/MiB * 8 bits/byte / 5 bits/sec / 3600 sec/hr = 15.95 hours It is an one time download, since, once you got it, the updates are cheap. Btw, it is a way small than a single CD needed for you to install Linux. If you want to get it and you're not willing to pay to a decent Internet connection, If only I could pay for a *decent* one. If I just want bandwidth at a poor level of service, poor reliability and high cost, then I'll pay for the local cable TV internet service. I'm in one of the white areas on the map on page 33 of: http://www.tccsmd.org/downloads/Broadband%20Final%20Report.pdf I don't really have options for getting a good value for my dollar on broadband internet. (The residential broadband deployment in the US is just terrible IMO.) just ask someone to get it for you and save on a CD. Nah. Next time I head to the library, I'll just bring a laptop along: free WiFi. Of course you can also keep using -hg. That was my plan. Regards, Andy 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
