Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
Hi Mauro, On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: Em 24-08-2011 10:25, Laurent Pinchart escreveu: On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or No. I am not in favor of conditional compilation in driver code. Actually, thinking some more about this, you should make the tvp514x driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the driver will become unusable by applications that are not MC-aware. Hosts/bridges don't have to export subdev nodes, they can just call subdev pad-level operations internally and let applications control the whole device through a single V4L2 video node. better, port the AM35x driver to the MC API. Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it doesn't have to expose them to userspace. I don't agree. If AM35x doesn't expose the MC API to userspace, CONFIG_MEDIA_CONTROLLER should not be required at all. Also, according with the Linux best practices, when #if tests for config symbols are required, developers should put it into the header files, and not inside the code, as it helps to improve code readability. From Documentation/SubmittingPatches: 2) #ifdefs are ugly Code cluttered with ifdefs is difficult to read and maintain. Don't do it. Instead, put your ifdefs in a header, and conditionally define 'static inline' functions, or macros, which are used in the code. Let the compiler optimize away the no-op case. So, this patch is perfectly fine on my eyes. I'm sorry, but I don't agree. Regarding the V4L2 subdev pad-level API, the goal is to convert all host and subdev drivers to it, so that's definitely the way to go. This does *not* mean that subdevs must expose a subdev device node. That's entirely optional. What I'm talking about is switching from video::*_mbus_fmt operations to pad::*_fmt operations. The pad-level format operations are very similar to video-level format operations, and more generic. Drivers shouldn't implement both. Regarding the MC API, drivers are not required to register a media_device instance. I have no issue with that. However, drivers should initialized the subdev's embedded media_entity, as that's required by subdev pad-level operations to get the number of pads for a subdev. This will result in no modification to the userspace. -- 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: How to git and build HVR-2200 drivers from Kernel labs ?
On 18/08/2011 2:20 AM, Steven Toth wrote: Eg should I use the source from git clone git://kernellabs.com/stoth/saa7164- dev.git or do you recommend something else that might be more stable ? pull a snapshot: http://www.kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=snapshot;h=87e0c0378bf2068df5d0c43acd66aea9ba71bd89;sf=tgz I've now got my card working with the saa7164 driver from the 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit. Many thanks for your help. -- 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: New Hauppauge HVR-2200 Revision?
Declan wrote: After putting the firmware files into place and doing a cold reboot, the card seems to be working fine. By working file I mean from the point of view of using it's DVB-T functionality within Mythtv. -- 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: New Hauppauge HVR-2200 Revision?
On 16/08/2011 5:03 AM, Adrien Dorsaz wrote: Hi, I've recently bought two cards HVR-2200 rev 0700:8940 and installed them into one PC. Kernel module saa7164 was launched by linux (under Ubuntu 11.04, with kernel 2.6.38-10-generic-pae), but it didn't recognize my cards (so, it selected card 0 : unknown). I've seen a new patch on your mailing list (see archive [1] and the patch [2]), but it was apparently only applied on kernellabs.org and not in the linuxtv.org archive. So I've downloaded the Ubuntu linux source (with apt-get install linux-source), I've patched it following the diff [2] and I've compiled this new kernel. Now when I reboot it, it works really well : I don't need any more to say which cards I've in /etc/modprobe.d/saa-7164.conf and both were well recognized (I've seen my four adapters in /dev/dvb/adapter[0,1,2,3]). So, could you apply this patch also on your source please (and try it to confirm my tests)? Thank you very much, Adrien Dorsaz a.dor...@gmail.com [1] : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14612.html , and the message which give a patch : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14626.html [2] : the patch on kernellabs.org : http://www.kernellabs.com/hg/saa7164-stable/rev/cf2d7530d676 -- 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 I've just done something similar. I installed the source code for my Ubuntu 10.10 x86 32bit kernel: apt-get source linux-image-2.6.35-30-generic-pae I got the source code of the version of the saa7164 driver that supports the 0700:8940 revision of the 2200 card from Kernel Labs by: git clone git://kernellabs.com/stoth/saa7164-stable.git cd saa7164-stable git checkout 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 make clean Many thanks to Steven Toth (driver author) for telling me about the 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit. I then replaced the Ubuntu kernal source's linux-2.6.35/drivers/media/video/saa7164/ directory with that from the above 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit and then recompiled the ubuntu kernel source. I found the instructions at http://linuxtweaking.blogspot.com/2010/05/how-to-compile-kernel-on-ubuntu-1004.htmlhttp://linuxtweaking.blogspot.com/2010/05/how-to-compile-kernel-on-ubuntu-1004.html for getting the ubuntu kernel source code and recompiling it most helpfull. I got the following firmware from http://www.steventoth.net/linux/hvr22xx : dvb-fe-tda10048-1.0.fw NXP7164-2010-03-10.1.fw After putting the firmware files into place and doing a cold reboot, the card's DVB-T functionality seems to be working fine within my Mythtv 0.24. Regards, Declan -- 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: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and
Em 04-09-2011 06:01, Laurent Pinchart escreveu: Hi Mauro, On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: Em 24-08-2011 10:25, Laurent Pinchart escreveu: On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com Fix the build break caused when CONFIG_MEDIA_CONTROLLER option is disabled and if any sensor driver has to be used between MC and non MC framework compatible devices. For example,if tvp514x video decoder driver migrated to MC framework is being built without CONFIG_MEDIA_CONTROLLER option enabled, the following error messages will result. drivers/built-in.o: In function `tvp514x_remove': drivers/media/video/tvp514x.c:1285: undefined reference to `media_entity_cleanup' drivers/built-in.o: In function `tvp514x_probe': drivers/media/video/tvp514x.c:1237: undefined reference to `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or No. I am not in favor of conditional compilation in driver code. Actually, thinking some more about this, you should make the tvp514x driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the driver will become unusable by applications that are not MC-aware. Hosts/bridges don't have to export subdev nodes, they can just call subdev pad-level operations internally and let applications control the whole device through a single V4L2 video node. better, port the AM35x driver to the MC API. Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it doesn't have to expose them to userspace. I don't agree. If AM35x doesn't expose the MC API to userspace, CONFIG_MEDIA_CONTROLLER should not be required at all. Also, according with the Linux best practices, when #if tests for config symbols are required, developers should put it into the header files, and not inside the code, as it helps to improve code readability. From Documentation/SubmittingPatches: 2) #ifdefs are ugly Code cluttered with ifdefs is difficult to read and maintain. Don't do it. Instead, put your ifdefs in a header, and conditionally define 'static inline' functions, or macros, which are used in the code. Let the compiler optimize away the no-op case. So, this patch is perfectly fine on my eyes. I'm sorry, but I don't agree. Regarding the V4L2 subdev pad-level API, the goal is to convert all host and subdev drivers to it, so that's definitely the way to go. This does *not* mean that subdevs must expose a subdev device node. That's entirely optional. What I'm talking about is switching from video::*_mbus_fmt operations to pad::*_fmt operations. The pad-level format operations are very similar to video-level format operations, and more generic. Drivers shouldn't implement both. I agree that implementing two ways for doing the same thing is a bad idea, but especially since your idea is to convert all subdevs to it, this type of conversion should not require enabling CONFIG_MEDIA_CONTROLLER, as this feature is used to enable the MC userspace API. Regarding the MC API, drivers are not required to register a media_device instance. I have no issue with that. However, drivers should initialized the subdev's embedded media_entity, as that's required by subdev pad-level operations to get the number of pads for a subdev. There are two solutions: 1) add some fallback method at the core to use the video::*_mbus_fmt way, when MC is disabled; 2) split the config options into two: one configurable by the user to enable the userspace MC API, and another, used internally that would select the MC internal API when drivers need it. As your plan is to convert all drivers to the new way, (2) doesn't make much sense in long term, as, at the end, all drivers will be selecting it. Also, I don't like the idea of increasing drivers complexity for the existing drivers that work properly without MC. All those core conversions that were done in the last two years caused already too much instability to them. We should really avoid touching on them again for something that won't be adding any new feature nor fixing any known bug. This will result in no
Re: [PATCH 1/2] DVB: dvb_frontend: convert semaphore to mutex
Em 26-08-2011 07:10, Andreas Oberritter escreveu: On 24.08.2011 20:54, Devin Heitmueller wrote: On Wed, Aug 24, 2011 at 2:08 PM, Andreas Oberritter o...@linuxtv.org wrote: Instead of wasting your time with theory, you could have easily reviewed my patch. It's really *very* simple any anyone having used semphores or mutexes in the kernel should be able to see that. There's no need to resort to belittlement. Both of us have a non-trivial number of commits to the Linux kernel. My concern is that in the kernel a semaphore with a unit of one is *not* necessarily the same as a mutex. In particular you need to take into account the calling context since mutexes do more enforcement of certain conditions that may have been acceptable for a semaphore. From http://www.kernel.org/doc/Documentation/mutex-design.txt : === - 'struct mutex' semantics are well-defined and are enforced if CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have virtually no debugging code or instrumentation. The mutex subsystem checks and enforces the following rules: * - only one task can hold the mutex at a time * - only the owner can unlock the mutex * - multiple unlocks are not permitted * - recursive locking is not permitted * - a mutex object must be initialized via the API * - a mutex object must not be initialized via memset or copying * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized * - mutexes may not be used in hardware or software interrupt * contexts such as tasklets and timers === and: === Disadvantages - The stricter mutex API means you cannot use mutexes the same way you can use semaphores: e.g. they cannot be used from an interrupt context, nor can they be unlocked from a different context that which acquired it. [ I'm not aware of any other (e.g. performance) disadvantages from using mutexes at the moment, please let me know if you find any. ] === In short, you cannot just arbitrarily replace one with the other. You need to look at all the possible call paths and ensure that there aren't any cases for example where the mutex is set in one but cleared in the other. Did you evaluate your change in the context of each of the differences described in the list above? You're right. There's one place where the semaphore is taken in user context and released by the frontend thread. I'm going to investigate whether this complicated locking is required. It might as well be possible to move the initialization steps from the beginning of the thread to dvb_frontend_start(), thus rendering this use of the semaphore unnecessary, and therefore making the code easier to understand and maintain. Ok, I'm dropping this patch from my queue. Unfortunately, I couldn't find any pointers as to why unlocking a mutex in a different context is not allowed. The only drawback seems to be a warning (which doesn't show up if there was any previous warning...), if mutex debugging is enabled. Besides that, I didn't notice any problem during runtime tests (on mips with SMP enabled). Maybe it affects only certain archs. I suggest you to look into the git history, and see when the mutex calls were added and when most semaphores were converted into mutexes. Probably, the comments there at git will provide you enough background. Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New Hauppauge HVR-2200 Revision?
On 16/08/2011 5:03 AM, Adrien Dorsaz wrote: Hi, I've recently bought two cards HVR-2200 rev 0700:8940 and installed them into one PC. Kernel module saa7164 was launched by linux (under Ubuntu 11.04, with kernel 2.6.38-10-generic-pae), but it didn't recognize my cards (so, it selected card 0 : unknown). I've seen a new patch on your mailing list (see archive [1] and the patch [2]), but it was apparently only applied on kernellabs.org and not in the linuxtv.org archive. So I've downloaded the Ubuntu linux source (with apt-get install linux-source), I've patched it following the diff [2] and I've compiled this new kernel. Now when I reboot it, it works really well : I don't need any more to say which cards I've in /etc/modprobe.d/saa-7164.conf and both were well recognized (I've seen my four adapters in /dev/dvb/adapter[0,1,2,3]). So, could you apply this patch also on your source please (and try it to confirm my tests)? Thank you very much, Adrien Dorsaz a.dor...@gmail.com [1] : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14612.html , and the message which give a patch : http://www.mail-archive.com/linux-media@vger.kernel.org/msg14626.html [2] : the patch on kernellabs.org : http://www.kernellabs.com/hg/saa7164-stable/rev/cf2d7530d676 -- 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 I've just done something similar. I installed the source code for my Ubuntu 10.10 x86 32bit kernel: apt-get source linux-image-2.6.35-30-generic-pae I got the source code of the version of the saa7164 driver that supports the 0700:8940 revision of the 2200 card from Kernel Labs by: git clone git://kernellabs.com/stoth/saa7164-stable.git cd saa7164-stable git checkout 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 make clean Many thanks to Steven Toth (driver author) for telling me about the 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit. I then replaced the Ubuntu kernal source's linux-2.6.35/drivers/media/video/saa7164/ directory with that from the above 87e0c0378bf2068df5d0c43acd66aea9ba71bd89 commit and then recompiled the ubuntu kernel source. I found the instructions at http://linuxtweaking.blogspot.com/2010/05/how-to-compile-kernel-on-ubuntu-1004.htmlhttp://linuxtweaking.blogspot.com/2010/05/how-to-compile-kernel-on-ubuntu-1004.html for getting the ubuntu kernel source code and recompiling it most helpfull. I got the following firmware from http://www.steventoth.net/linux/hvr22xx : dvb-fe-tda10048-1.0.fw NXP7164-2010-03-10.1.fw After putting the firmware files into place and doing a cold reboot, the card seems to be working fine. Regards, Declan -- 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
spca1528 device (Device 015: ID 04fc:1528 Sunplus Technology)..libv4l2: error turning on stream: Timer expired issue
Hi guys, Not sure if is the right place to ask since this device use a gspca driver and not sure if that driver is related to uvc or not, if not please point me to the right place... Recently I'm trying to make work a Sunplus crappy mini HD USB camera, lsusb list this info related to the device: Picture Transfer Protocol (PIMA 15470) Bus 001 Device 015: ID 04fc:1528 Sunplus Technology Co., Ltd idVendor 0x04fc Sunplus Technology Co., Ltd idProduct 0x1528 bcdDevice1.00 iManufacturer 1 Sunplus Co Ltd iProduct2 General Image Devic iSerial 0 ... Using the gspca-2.13.6 on my Fed12 (2.6.31.6-166.fc12.i686.PAE kernel), the device is listed as /dev/video1 and no error doing a dmesg...but trying to make it work, let say with xawtv, I get: This is xawtv-3.95, running on Linux/i686 (2.6.31.6-166.fc12.i686.PAE) xinerama 0: 1600x900+0+0 WARNING: No DGA direct video mode for this display. /dev/video1 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion libv4l2: error turning on stream: Timer expired ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout ..or doing: xawtv -c /dev/video1 -nodga -novm -norandr -noxv -noxv-video I get: ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout libv4l2: error turning on stream: Timer expired libv4l2: error reading: Invalid argument vlc, cheese, etc give me similar Timeout related messages... I read some post about similar devices (but ID 12 or 14) that successfully works with gspca, so it seems that this one is close to work but may be need a fix on some timeout or something similar on the driver... Any clue of what can be done?..any suggestions or right place to ask?, do you need any other info to help to dig into the problem? Thanks a lot. Mauricio -- Mauricio R. Henriquez Schott Escuela de Ingeniería en Computación Universidad Austral de Chile - Sede Puerto Montt Los Pinos S/N, Balneario de Pelluco, Puerto Montt - Chile Tel: 65-487440 Fax: 65-277156 mail: mauriciohenriq...@uach.cl attachment: buhochileno.vcf
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Sep 4 19:00:44 CEST 2011 git hash:1b19e42952963ae2a09a655f487de15b7c81c5b7 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: [PATCH]Medion 95700 analog video support
W dniu 04.09.2011 21:05, Arnaud Lacombe pisze: Hi, On Sun, Sep 4, 2011 at 2:51 PM, Maciej Szmigiero m...@o2.pl wrote: This patch adds support for analog part of Medion 95700 in the cxusb driver. For what reason am I CC'ed on this ? Most of the relevant changes I ever made in the media tree were only mechanical. Thanks, - Arnaud Hi, get_maintainer.pl script output on this patch returned your name, thats why it was included. If thats a mistake I'm sorry for spamming you. Best regards, Maciej Szmigiero -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.2] [media] em28xx: use atomic bit operations for devices-in-use mask
On 04/09/11 00:49, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] em28xx: use atomic bit operations for devices-in-use mask Author: Chris Rankinranki...@yahoo.com Date:Sat Aug 20 08:21:03 2011 -0300 Use atomic bit operations for the em28xx_devused mask, to prevent an unlikely race condition should two adapters be plugged in simultaneously. The operations also clearer than explicit bit manipulation anyway. Signed-off-by: Chris Rankinranki...@yahoo.com Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com drivers/media/video/em28xx/em28xx-cards.c | 33 ++--- 1 files changed, 16 insertions(+), 17 deletions(-) Hi Mauro, I think you missed this line in the merge. Cheers, Chris --- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-04 20:17:00.0 +0100 +++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-04 20:19:21.0 +0100 @@ -3083,7 +3083,6 @@ em28xx_err(DRIVER_NAME This is an anciliary interface not used by the driver\n); -em28xx_devused = ~(1nr); retval = -ENODEV; goto err; }
Re: DM04 USB DVB-S TUNER
On Sat, 2011-06-25 at 22:10 +0100, Malcolm Priestley wrote: On Wed, 2011-06-08 at 16:20 +0100, Malcolm Priestley wrote: On Wed, 2011-06-08 at 14:18 +0300, Mehmet Altan Pire wrote: 07-06-2011 22:34, Malcolm Priestley yazmış: On Tue, 2011-06-07 at 06:31 +0100, Malcolm Priestley wrote: On Tue, 2011-06-07 at 02:28 +0300, Mehmet Altan Pire wrote: 06-06-2011 00:47, Malcolm Priestley yazmış: On Sun, 2011-06-05 at 21:42 +0100, Malcolm Priestley wrote: On Sun, 2011-06-05 at 19:34 +0300, Mehmet Altan Pire wrote: 05-06-2011 17:16, Malcolm Priestley yazmış: On Sun, 2011-06-05 at 03:35 +0300, Mehmet Altan Pire wrote: Hi, I have DM04 USB DVBS TUNER, using ubuntu with v4l media-build drivers/modules but device doesn't working (unknown device). lsusb message: ID 3344:22f0 under of the box: DM04P2011050176 Yes, i have windows xp driver, name is US2B0D.sys I sending it, attached in this mail. Thanks. Here is a modified lmedm04.c and lme2510b_fw.sh using the US2B0D.sys to modify the interrupt return. Ok, i tested it. Device recognized on WinXP with original driver, but tv application says no lock. I'm not sure it worked on WinXP but driver cd is original and succesfully loaded and recognized. Again tested on ubuntu with new lmedm04.c and lme2510b_fw.sh than make, make install, and restart. lsusb says: Bus 001 Device 008: ID 3344:1120 (changes 22f0 to 1120) dmesg says: Yes this should happen. The firmware will reboot with the correct id. My device different or chip is damaged? Label, box and driver cd title writes DM04P. DM04 and DM04P different devices? I think the id of the chip is faulty or default. I will test the firmware with LG tuner later. It is not the LG, s7395 or S0194 tuner. So the id is intentional. How does it identify itself in windows? tvboxspy 3. Tests :WinXP Test: I'm sure it worked on WinXP now. Tested with ProgDVB application. Signal, channel search and watching tv as succesfully. My Device working without problems on WinXP and it's not damaged. When device running on stream, green led is active, if not running, green led is passive (red led is power led and it's always active). Driver Info: LME_PCTV_DVBS_RS2000 VID3344 PID22F0 22f0 this number correct... I need to find out what exactly the RS2000 tuner is. So currently the linux driver is not supported with your device. A little update... I now have one of these devices. The chip is actually a M8BRS2000 which is a combi frontend/tuner device. The ID is confirmed as 3344:22f0, it appears to be patched by the Windows Driver as 3344:1120 devices try wrongly to use the RS2000 driver. There is no Linux frontend driver for this device. I will start to write one shortly, so support could be several months away. I have written the M8BRS2000 frontend, which has been on test for the last two weeks. Unfortunately, on Friday my device has partially failed, in that the m8brs2000 chip starts to fail with prolonged use. It seems to be an heat issue as cooling the device restores normal operation. I will do some more tests in a lab this week for dry-joints. Have you or anyone else noticed any similar problems running the device under Windows? This means the device driver for Linux is back on Alpha and cannot be released. Regards Malcolm -- 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 1/1] EM28xx - Fix memory leak on disconnect or error.
Mauro,
This patch seems to have been missed, so I'm resending it.
Release the dev-alt_max_pkt_size buffer in all cases.
Signed-off-by: Chris Rankin ranki...@yahoo.com
Cheers,
Chris
--- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-04 20:30:14.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-04 20:28:59.0 +0100
@@ -3200,6 +3200,7 @@
retval = em28xx_init_dev(dev, udev, interface, nr);
if (retval) {
mutex_unlock(dev-lock);
+ kfree(dev-alt_max_pkt_size);
kfree(dev);
goto err;
}
--- linux/drivers/media/video/em28xx/em28xx-video.c.orig 2011-09-04 20:16:52.0 +0100
+++ linux/drivers/media/video/em28xx/em28xx-video.c 2011-09-04 20:27:41.0 +0100
@@ -2200,6 +2200,7 @@
free the remaining resources */
if (dev-state DEV_DISCONNECTED) {
em28xx_release_resources(dev);
+ kfree(dev-alt_max_pkt_size);
kfree(dev);
return 0;
}
Re: [PATCH]Medion 95700 analog video support
W dniu 04.09.2011 21:46, Michael Krufky pisze: Maciej, I'm excited to see some success getting analog to work in the dvb-usb framework. Some people have been asking for this support in the cxusb driver for a long time. I have a device (DViCO FusionHDTV5 usb) that should work with this patch with some small modifications -- i will try it out. I see that this patch adds analog support to cxusb... have you thought at all about adding generic analog support callbacks to the dvb-usb framework? There are some other dvb-usb devices based on the dib0700 chipset that also also use the cx25840 decoder for analog -- it would be great if this can be done in a way to benefit both the dib0700 and cxusb drivers. I will let you know how things go after I try this code on my own device, here. Thanks for your patch. -Mike Krufky Hi and thanks for reply, I think whether the code should be moved to dvb-usb framework really depends on how much the devices have in common - Medion uses a generic Cypress FX2 USB bridge which is programmed (by firmware) to post an ISO buffer once there is exactly 1010 bytes received on its parallel interface. This parallel interface is 8-bit wide and has data inputs connected to cx25840 video interface data output and clock input to cx25840 pixel clock output. USB bridge does not modify this data in any way, nor it does any alignment. So we have a raw BT.656 (or VESA VIP) stream coming from the device. Because there are 3 such 1010-byte packets per (micro)frame the URB frame descriptor has to be 3030 bytes in length (or more) or data will be truncated, which will result in parts of field being all-green. If your device has similar characteristics then it is just matter of substituting a few commands in code (and maybe changing CXUSB_VIDEO_PKT_SIZE to different value if it does not use 3*1010 byte frames). Otherwise, for example if device outputs simple YUV data without any framing, the code will pretty much be different - other than a bit of V4L2 driver glue code which can be shared. Best regards and hope this helps, Maciej Szmigiero -- 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 v2] [media] vp702x: fix buffer handling
On Fri, 26 Aug 2011 00:11:15 +0200 Florian Mickler flor...@mickler.org wrote: In my previous change to this driver, I was not aware, that dvb_usb_device_init calls the frontend_attach routine which needs a transfer buffer. So we can not setup anything private in the probe routine beforehand but have to allocate when needed. This means also that we cannot use a private buffer mutex to serialize that buffer but instead need to use the dvb_usb_device's usb_mutex. Fixes: https://bugzilla.novell.com/show_bug.cgi?id=709440 Tested-by: Markus Stephan markus_step...@freenet.de Signed-off-by: Florian Mickler flor...@mickler.org --- So, someone who could test that driver found me after all. I renamed the functions to get rid of that ugly and pointless _unlocked suffix I deliriously added earlier. Markus tested this patch modulo function renaming. I am so shure that this version will still work for him, that I already added his Tested-by. *fingerscrossed* Hi Mauro! I just checked patchwork and in case you hold off on this because of my *fingerscrossed* remark above: Markus reported off-list that this version still works for him. Regards, Flo -- 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
ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 regards Antti -- http://palosaari.fi/ -- 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: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
On 05/09/11 00:46, Antti Palosaari wrote: Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 The function em28xx_add_into_devlist() should have been deleted as part of this change: http://git.linuxtv.org/media_tree.git?a=commitdiff;h=6c03e38b34dcfcdfa2f10cf984995a48f030f039 Its only reference should have been removed at the same time. Cheers, Chris -- 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: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
On 05/09/11 00:46, Antti Palosaari wrote: Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 I think I see what's happened here. An extra reference to em28xx_add_into_devlist() has been added to em28xx_init_dev() at line 2888. This reference can be deleted because em28xx_init_extension() has been modified to add the struct em28xx to the devlist and then pass it to each extension's init() function all as a single operation. Cheers, Chris -- 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: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
On 09/05/2011 03:15 AM, Chris Rankin wrote: On 05/09/11 00:46, Antti Palosaari wrote: Moikka, Current linux-media make gives error. Any idea what's wrong? Kernel: arch/x86/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 1907 modules ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 The function em28xx_add_into_devlist() should have been deleted as part of this change: http://git.linuxtv.org/media_tree.git?a=commitdiff;h=6c03e38b34dcfcdfa2f10cf984995a48f030f039 Its only reference should have been removed at the same time. git grep m28xx_add_into_devlis drivers/media/ drivers/media/video/em28xx/em28xx-cards.c: em28xx_add_into_devlist(dev); drivers/media/video/em28xx/em28xx.h:void em28xx_add_into_devlist(struct em28xx *dev); If you select em28xx-cards.c blob link you give you can see it is there still for some reason. regards Antti -- http://palosaari.fi/ -- 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: ERROR: em28xx_add_into_devlist [drivers/media/video/em28xx/em28xx.ko] undefined!
On 05/09/11 01:24, Antti Palosaari wrote: If you select em28xx-cards.c blob link you give you can see it is there still for some reason. It's a merge issue. This lingering reference must have been added after I posted my original patch. Fortunately, it's easily fixed: the list_add_tail(dev-devlist, em28xx_devlist); operation is now done by ex28xx_init_extension() instead, meaning we only take the devlist mutex once. So that last em28xx_add_into_devlist() reference is obsolete. Cheers, Chris -- 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: spca1528 device (Device 015: ID 04fc:1528 Sunplus Technology)..libv4l2: error turning on stream: Timer expired issue
On Sun, 4 Sep 2011, Mauricio Henriquez wrote: Hi guys, Not sure if is the right place to ask since this device use a gspca driver and not sure if that driver is related to uvc or not, if not please point me to the right place... Looks right to me, and I hope that someone has more direct knowledge about your camera, which I do not. I do have a couple of questions, however, and a comment. Recently I'm trying to make work a Sunplus crappy mini HD USB camera, lsusb list this info related to the device: Picture Transfer Protocol (PIMA 15470) Bus 001 Device 015: ID 04fc:1528 Sunplus Technology Co., Ltd idVendor 0x04fc Sunplus Technology Co., Ltd idProduct 0x1528 bcdDevice1.00 iManufacturer 1 Sunplus Co Ltd iProduct2 General Image Devic iSerial 0 ... Using the gspca-2.13.6 on my Fed12 (2.6.31.6-166.fc12.i686.PAE kernel), the device is listed as /dev/video1 and no error doing a dmesg...but trying to make it work, let say with xawtv, I get: This is xawtv-3.95, running on Linux/i686 (2.6.31.6-166.fc12.i686.PAE) xinerama 0: 1600x900+0+0 WARNING: No DGA direct video mode for this display. /dev/video1 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion libv4l2: error turning on stream: Timer expired ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout ..or doing: xawtv -c /dev/video1 -nodga -novm -norandr -noxv -noxv-video I get: ioctl: VIDIOC_STREAMON(int=1): Timer expired ioctl: VIDIOC_S_STD(std=0x0 []): Invalid argument v4l2: oops: select timeout libv4l2: error turning on stream: Timer expired libv4l2: error reading: Invalid argument vlc, cheese, etc give me similar Timeout related messages... The comment: Perhaps a good thing to try would be the nice, simple, basic program svv, which you can get from the website of Jean-Francois Moine. Some of these other things do not always work. Especially I have had trouble with xawtv, though the xawtv people may have fixed a lot of problems while I was not watching them. The question: Is this a dual-mode camera which is also supposed to have still camera capabilities? If so, you might be interested in contacting the Gphoto project. I just searched for it there, and it does not seem to be listed. I assume that the specialists on the spca cameras will step forward. I am not one of them, as I said. Good luck. Theodore Kilgore -- 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 15/21] [staging] tm6000: Execute lightweight reset on close.
* Mauro Carvalho Chehab wrote:
Em 01-09-2011 02:24, Thierry Reding escreveu:
* Mauro Carvalho Chehab wrote:
Em 31-08-2011 17:53, Mauro Carvalho Chehab escreveu:
Em 04-08-2011 04:14, Thierry Reding escreveu:
When the last user closes the device, perform a lightweight reset of the
device to bring it into a well-known state.
Note that this is not always enough with the TM6010, which sometimes
needs a hard reset to get into a working state again.
---
drivers/staging/tm6000/tm6000-core.c | 43
+
drivers/staging/tm6000/tm6000-video.c |8 +-
drivers/staging/tm6000/tm6000.h |1 +
3 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 317ab7e..58c1399 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -597,6 +597,49 @@ int tm6000_init(struct tm6000_core *dev)
return rc;
}
+int tm6000_reset(struct tm6000_core *dev)
+{
+int pipe;
+int err;
+
+msleep(500);
+
+err = usb_set_interface(dev-udev,
dev-isoc_in.bInterfaceNumber, 0);
+if (err 0) {
+tm6000_err(failed to select interface %d, alt. setting
0\n,
+dev-isoc_in.bInterfaceNumber);
+return err;
+}
+
+err = usb_reset_configuration(dev-udev);
+if (err 0) {
+tm6000_err(failed to reset configuration\n);
+return err;
+}
+
+msleep(5);
+
+err = usb_set_interface(dev-udev,
dev-isoc_in.bInterfaceNumber, 2);
+if (err 0) {
+tm6000_err(failed to select interface %d, alt. setting
2\n,
+dev-isoc_in.bInterfaceNumber);
+return err;
+}
+
+msleep(5);
+
+pipe = usb_rcvintpipe(dev-udev,
+dev-int_in.endp-desc.bEndpointAddress
USB_ENDPOINT_NUMBER_MASK);
+
+err = usb_clear_halt(dev-udev, pipe);
+if (err 0) {
+tm6000_err(usb_clear_halt failed: %d\n, err);
+return err;
+}
+
+return 0;
+}
+
int tm6000_set_audio_bitrate(struct tm6000_core *dev, int bitrate)
{
int val = 0;
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 492ec73..70fc19e 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -1503,7 +1503,6 @@ static int tm6000_open(struct file *file)
tm6000_get_std_res(dev);
file-private_data = fh;
-fh-vdev = vdev;
fh-dev = dev;
fh-radio = radio;
fh-type = type;
@@ -1606,9 +1605,16 @@ static int tm6000_release(struct file *file)
dev-users--;
res_free(dev, fh);
+
if (!dev-users) {
+int err;
+
tm6000_uninit_isoc(dev);
videobuf_mmap_free(fh-vb_vidq);
+
+err = tm6000_reset(dev);
+if (err 0)
+dev_err(vdev-dev, reset failed: %d\n, err);
}
kfree(fh);
diff --git a/drivers/staging/tm6000/tm6000.h
b/drivers/staging/tm6000/tm6000.h
index cf57e1e..dac2063 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -311,6 +311,7 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
req, u16 value,
u16 index, u16 mask);
int tm6000_i2c_reset(struct tm6000_core *dev, u16 tsleep);
int tm6000_init(struct tm6000_core *dev);
+int tm6000_reset(struct tm6000_core *dev);
int tm6000_init_analog_mode(struct tm6000_core *dev);
int tm6000_init_digital_mode(struct tm6000_core *dev);
Something went wrong with the patchset. Got an OOPS during device probe.
Maybe it were caused due to udev, that opens V4L devices, as soon as
they're
registered.
int tm6000_reset(struct tm6000_core *dev)
{
...
msleep(5);
pipe = usb_rcvintpipe(dev-udev,
dev-int_in.endp-desc.bEndpointAddress
USB_ENDPOINT_NUMBER_MASK);
The bug is on the above line. It seems that usb_rcvintpipe() didn't like
to be
called before the end of the device registration code.
I fail to see how this can happen. tm6000_reset() is only called when the
last user closes the file. Since the file can only be opened in the first
place when the device has been registered, tm6000_reset() should never be
called before the device is registered.
It is quite simple: not all tm5600/6000/6010 devices have int_in endpoints.
The enclosed patch fixes it. Tested on a Saphire Wonder TV device
