Re: [PATCH] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
On Wednesday 04 of November 2009, HoP wrote: Hi Hermann, Attached patch adds two optional (so, disabled by default and therefore could not break any compatibility) features: 1, tone_control=1 When enabled, ISL6421 overrides frontend's tone control function (fe-ops.set_tone) by its own one. On your comments, the better is to describe why someone would need to use such option. You should also add a quick hint about that at the option description. Well, I'm not sure I can make some good hint why such option can be useful by someone. I can only say that isl6121 has possibility to drive 22k tone, so why not enable usage of it? well, we have much more experienced guys than me here on that, but it should be device specific then. Of course, we made such code because we were using exactly this way of 22k control in our device. So the demod can't do it or just free choice? Well, more detailed Ales can speak about it, he is hw guy here :) Anyway, regardless reason of choice important is that isl6421 can be used this way and, may be even more important, it is used (and works correctly) in our hardware. I understand it can be a bit non-usual way of usage, but as I said, it works for us :) When using isl6421 it is one possible way how to modulate LNB voltage with 22kHz tone. The interesting is that if frontend is capable to support such function it doesn't need any additional hw. 2, overcurrent_enable=1 When enabled, overcurrent protection is disabled during sending diseqc command. Such option is usable when ISL6421 catch overcurrent threshold and starts limiting output. Note: protection is disabled only during sending of diseqc command, until next set_tone() usage. What typically means only max up to few hundreds of ms. WARNING: overcurrent_enable=1 is dangerous and can damage your device. Use with care and only if you really know what you do. I'm not sure if it is a good idea to have this... Why/when someone would need this? I know that it is a bit dangerous option, so I can understand you can don't like it :) But I would like to note again - such way of using is permitted by datasheet (otherwise it would not be even possible to enable it) and we learnt when used correctly (it is enabled only within diseqc sequence), it boost rotor moving or fixes using some power-eating diseqc switches. If you still feel it is better to not support bit strange mode, then I can live with #if 0 commented out blocks or adding some kernel config option with something like ISL6421_ENABLE_OVERCURRENT or so. Question is, can you melt down some chip with it or not? If you can, stay away, since this was not in the scope earlier. We have tested it with few devices (both rotor and diseqc switches) and have not ran in any damage yet. TBH, I'm writing about possibility of damage only because of understanding that if I disable overcurrent safeguard I can imagine it can end up bad way. But not tested on our side. Regards /Honza This is used in way I hope it was supposed to by designers of the chip. The current to LNB is in real not unlimited, it is limited by hw design (sense resistor in FET circuit). So not isl6421 nor connected FET should be damaged even when short circuit appears in antenna connection, but as in most of cases this feature is not needed we add it as optional parameter. Of course hw designer should take care of power dissipation from the circuit. Let me cite the isl6421 datasheet: However, there could be some cases in which a highly capacitive load on the output may cause a difficult start-up, when the dynamic protection is chosen. This can be solved by initiating a power start-up in static mode (DCL = HIGH) and then switching to the dynamic mode (DCL = LOW) after a chosen amount of time. When in static mode, the OLF bit goes HIGH when the current clamp limit is reached and returns LOW when the overload condition is cleared. The OLF bit will be LOW at the end of initial power-on soft-start. This is exactly situation in which we find ourselves when testing our hw with cascade of diseqc switch and diseqc motor. The proposed patch and activating of temporarily disabling the dynamic current limitations solved this problem perfectly. BR, Ales -- 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
TT S2-1600 and NOVA-HD-S2 tuning problems on some transponders
Hi. I have two S2-1600 and one NOVA-HD-S2 with a quad LNB at 1.0W (http://www.lyngsat.com/packages/canaldigital.html) and excellent reception on most transponders running 2.6.31.1 and dvb drivers from latest hg. I have troubles with both cards, though. The NOVA-HD-S2 does not lock on transponders with SR's of 25000 and 3, but on all others (24500,27800,28000). Any ideas what causes that? The 3 I can understand, but 25000? The S2-1600's are more inconsistent. They have problems tuning to 11421, 12130, 12226 and 12341 MHz. Sometimes they do and once locked, they run forever with perfect reception. I don't understand why there's a problem with these transponders since they tune just fine to transponders with the same SR, polarisation and nearby frequencies. Very greateful for any input. Best regards and thanks to all involved in LinuxTV, /Magnus H -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] NOVA-TD exeriences?
Zdenek Kabelac wrote: 2009/11/3 Zdenek Kabelac zdenek.kabe...@gmail.com: 2009/11/2 Soeren Moch soeren.m...@stud.uni-hannover.de: Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the NOVA-T. The NOVA-T has always worked perfectly here but I would like to know if the -TD will do the job of two NOVA-T's. And there also seems to be a new version out with two small antenna connectors instead of the previous configuration. Anyone tried it? Does it come with an antenna adaptor cable? http://www.hauppauge.de/de/pics/novatdstick_top.jpg Thankful for any info. Well I've this usb stick with these two small connectors - and it runs just fine. Though I think there is some problem with suspend/resume recently (2.6.32-rc5) and it needs some inspection. But it works just fine for dual dvb-t viewing. And yes - it contains two small antennas with small connectors and one adapter for normal antenna - i.e. 1 antenna input goes to 2 small antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? I'll recheck in the evening whether there are no regression, but I've been able to get 3 dvb-t independent (different mux) TV streams (with the usage of the second stick Aver Hybrid Volar HX proprietary Aver driver) with 2.6.29/30 vanilla kernels played at the same time on my C2D T61. Ok - I could confirm, I'm able to play two different muxes at the same time from this USB stick. And I do not experience any stream damage. I'm running Fedora Rawhide with vanilla kernel 2.6.32-rc5, kaffeine 0.8.7 for the first adapter and relatively fresh mplayer compilation for the second adapter Thought there are things to be reported and fixed (some USB regression I guess) - I'll handle this via lkml. Anyway here is dmesg USB stick identification (labeled WinTV Nova-TD) USB device found, idVendor=2040, idProduct=5200 USB device strings: Mfr=1, Product=2, SerialNumber=3 Product: NovaT 500Stick Regards Zdenek Very strange. Playing of two different muxes is also no problem for me, as long as no new stream is started (of course after switching off one of the streams before). In the start moment of the new the stream the already running stream is disturbed and I see a demaged group of pictures in the old stream. After these few pictures the stream is running fine again. I cannot imagine that this is a specific problem of my stick, however, thank you for testing! Regards, Soeren -- 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: TT S2-1600 and NOVA-HD-S2 tuning problems on some transponders
Hi Magnus, Magnus Hörlin schrieb: The S2-1600's are more inconsistent. They have problems tuning to 11421, 12130, 12226 and 12341 MHz. Sometimes they do and once locked, they run forever with perfect reception. I don't understand why there's a problem with these transponders since they tune just fine to transponders with the same SR, polarisation and nearby frequencies. Very greateful for any input. The stv090x driver as it is in current hg repository has some known issues with locking reliability. Please try the patches that I sent two days ago to the list. 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
Re: [PATCH] isl6421.c - added optional features: tone control and temporary diseqc overcurrent
Hi Ales and HoP, Em Wed, 4 Nov 2009 09:35:51 +0100 Ales Jurik aju...@quick.cz escreveu: On Wednesday 04 of November 2009, HoP wrote: Hi Hermann, Attached patch adds two optional (so, disabled by default and therefore could not break any compatibility) features: 1, tone_control=1 When enabled, ISL6421 overrides frontend's tone control function (fe-ops.set_tone) by its own one. On your comments, the better is to describe why someone would need to use such option. You should also add a quick hint about that at the option description. Well, I'm not sure I can make some good hint why such option can be useful by someone. I can only say that isl6121 has possibility to drive 22k tone, so why not enable usage of it? well, we have much more experienced guys than me here on that, but it should be device specific then. Of course, we made such code because we were using exactly this way of 22k control in our device. So the demod can't do it or just free choice? Well, more detailed Ales can speak about it, he is hw guy here :) Anyway, regardless reason of choice important is that isl6421 can be used this way and, may be even more important, it is used (and works correctly) in our hardware. I understand it can be a bit non-usual way of usage, but as I said, it works for us :) When using isl6421 it is one possible way how to modulate LNB voltage with 22kHz tone. The interesting is that if frontend is capable to support such function it doesn't need any additional hw. 2, overcurrent_enable=1 When enabled, overcurrent protection is disabled during sending diseqc command. Such option is usable when ISL6421 catch overcurrent threshold and starts limiting output. Note: protection is disabled only during sending of diseqc command, until next set_tone() usage. What typically means only max up to few hundreds of ms. WARNING: overcurrent_enable=1 is dangerous and can damage your device. Use with care and only if you really know what you do. I'm not sure if it is a good idea to have this... Why/when someone would need this? I know that it is a bit dangerous option, so I can understand you can don't like it :) But I would like to note again - such way of using is permitted by datasheet (otherwise it would not be even possible to enable it) and we learnt when used correctly (it is enabled only within diseqc sequence), it boost rotor moving or fixes using some power-eating diseqc switches. If you still feel it is better to not support bit strange mode, then I can live with #if 0 commented out blocks or adding some kernel config option with something like ISL6421_ENABLE_OVERCURRENT or so. Question is, can you melt down some chip with it or not? If you can, stay away, since this was not in the scope earlier. We have tested it with few devices (both rotor and diseqc switches) and have not ran in any damage yet. TBH, I'm writing about possibility of damage only because of understanding that if I disable overcurrent safeguard I can imagine it can end up bad way. But not tested on our side. Regards /Honza This is used in way I hope it was supposed to by designers of the chip. The current to LNB is in real not unlimited, it is limited by hw design (sense resistor in FET circuit). So not isl6421 nor connected FET should be damaged even when short circuit appears in antenna connection, but as in most of cases this feature is not needed we add it as optional parameter. Of course hw designer should take care of power dissipation from the circuit. Let me cite the isl6421 datasheet: However, there could be some cases in which a highly capacitive load on the output may cause a difficult start-up, when the dynamic protection is chosen. This can be solved by initiating a power start-up in static mode (DCL = HIGH) and then switching to the dynamic mode (DCL = LOW) after a chosen amount of time. When in static mode, the OLF bit goes HIGH when the current clamp limit is reached and returns LOW when the overload condition is cleared. The OLF bit will be LOW at the end of initial power-on soft-start. This is exactly situation in which we find ourselves when testing our hw with cascade of diseqc switch and diseqc motor. The proposed patch and activating of temporarily disabling the dynamic current limitations solved this problem perfectly. Your arguments make sense for me, but not as a patch for adding two extra parameters that any user can try to enable as a trial to make their board work. It should be, instead, mapped as two parameters at the frontend structure, and sent us together with the driver (or with the patch for an existing driver) that needs such features. In the specific case of disabling the
Re: [linux-dvb] NOVA-TD exeriences?
2009/11/4 Soeren Moch soeren.m...@stud.uni-hannover.de: Zdenek Kabelac wrote: 2009/11/3 Zdenek Kabelac zdenek.kabe...@gmail.com: 2009/11/2 Soeren Moch soeren.m...@stud.uni-hannover.de: Hi. I would be happy to hear if anyone has tried both the NOVA-TD and the NOVA-T. The NOVA-T has always worked perfectly here but I would like to know if the -TD will do the job of two NOVA-T's. And there also seems to be a new version out with two small antenna connectors instead of the previous configuration. Anyone tried it? Does it come with an antenna adaptor cable? http://www.hauppauge.de/de/pics/novatdstick_top.jpg Thankful for any info. Well I've this usb stick with these two small connectors - and it runs just fine. Though I think there is some problem with suspend/resume recently (2.6.32-rc5) and it needs some inspection. But it works just fine for dual dvb-t viewing. And yes - it contains two small antennas with small connectors and one adapter for normal antenna - i.e. 1 antenna input goes to 2 small antenna connectors. zdenek, your nova-td stick works just fine for dual dvb-t viewing? I always had this problem: When one channel is streaming and the other channel is switched on, the stream of the already running channel gets broken. see also: http://www.mail-archive.com/linux-media@vger.kernel.org/msg06376.html Can you please test this case on your nova-td stick? I'll recheck in the evening whether there are no regression, but I've been able to get 3 dvb-t independent (different mux) TV streams (with the usage of the second stick Aver Hybrid Volar HX proprietary Aver driver) with 2.6.29/30 vanilla kernels played at the same time on my C2D T61. Ok - I could confirm, I'm able to play two different muxes at the same time from this USB stick. And I do not experience any stream damage. I'm running Fedora Rawhide with vanilla kernel 2.6.32-rc5, kaffeine 0.8.7 for the first adapter and relatively fresh mplayer compilation for the second adapter Thought there are things to be reported and fixed (some USB regression I guess) - I'll handle this via lkml. Anyway here is dmesg USB stick identification (labeled WinTV Nova-TD) USB device found, idVendor=2040, idProduct=5200 USB device strings: Mfr=1, Product=2, SerialNumber=3 Product: NovaT 500Stick Regards Zdenek Very strange. Playing of two different muxes is also no problem for me, as long as no new stream is started (of course after switching off one of the streams before). In the start moment of the new the stream the already running stream is disturbed and I see a demaged group of pictures in the old stream. After these few pictures the stream is running fine again. I cannot imagine that this is a specific problem of my stick, however, thank you for testing! Hmm - well I haven't made a close inspection (frame by frame) of every frame during the startup of second player. Kaffaine seems to have blocked screen refresh because Xorg gets locked via starting mplayer. So there is definitely frame skipping viewing experience - but that's the flaw of Xorg - sound is played just fine. If I should check whether there are no TS stream errors only at the moment of startup, I'll need to grab both streams and make a better analysis. My current statement was purely based on the fact, that I could watch both channels without any picture artefacts or sound distorsion - but during startup there is surelly a period, when some frames are not even visibile, because kaffeine cannot even refresh playing window - but that's another story Zdenek -- 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: Trying to compile for kernel version 2.6.28
Thanks a lot. Only syncing my sources every 2 months, I forgot about the make allmodconfig I keep http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2. in sync until Antti's sources have been tested, and IR support is put in, so that these sticks can be supported from the normal kernel. Mauro Carvalho Chehab wrote: Hi Jan, Em Tue, 03 Nov 2009 16:45:15 +0100 Jan Hoogenraad jan-conceptro...@hoogenraad.net escreveu: At this moment, I cannot figure out how to compile v4l with kernel version 2.6.28. I see, however, that the daily build reports: linux-2.6.28-i686: OK Yes, and that's correct. It does compile from scratch with 2.6.28. If you look at v4l/versions.txt, this is already marked to compile only with kernels 2.6.31 or newer. It should be noticed, however, that the building system won't touch at your .config if you just do an hg update (or hg pull -u). You'll need to ask it explicitly to process versions.txt again, by calling one of the alternatives bellow that re-generates a v4l/.config. If you are using a customized config, you'll need to call either one of those: make menuconfig make config make xconfig or make gconfig (in this specific case, just entering there and saving the config is enough - there's no need to touch on any items) Or, at the simple case were you're just building everything, you'll need to do: make allmodconfig A side effect of touching at v4l/.config is that all (selected) drivers will recompile again. Cheers, Mauro -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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 5/8] drivers/media/video/uvc: Use %pUl to print UUIDs
Hi Joe, On Saturday 31 October 2009 20:27:38 Joe Perches wrote: On Sat, 2009-10-31 at 20:10 +0100, Laurent Pinchart wrote: On Saturday 31 October 2009 10:07:01 Mauro Carvalho Chehab wrote: I'm assuming that those printk patches from Joe to uvc will go via your tree, so please submit a pull request when they'll be ready for upstream. I'll submit the pull request as soon as the printk core patch hits upstream. I believe Andrew Morton has picked up the patches for his mm-commits set. If you do nothing, these should show up in Linus' tree after awhile. Thanks for the notice. Andrew, could you please drop drivers-media-video-uvc-use-%pul-to-print- uuids.patch ? I will push it through the v4l-dvb tree as I need to add backward compatibility support. -- 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: MSI StarCam Racer - No valid video chain found
Hi Martin, On Monday 02 November 2009 21:31:50 Martin Rod wrote: Hi Laurent, I send you output of lsusb. I think, that the uvcdriver is the latest. I try older kernel tomorrow. Could you please load the driver with trace=255 (modprobe uvcvideo trace=255) or, if the driver is already loaded, change the trace parameter to 255 (echo 255 /sys/module/uvcvideo/parameters/trace), plug your camera and send me the messages printed by the uvcvideo driver to the kernel log? Thanks. -- 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
[PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/uvcvideo/ for the following 4 changesets: uvcvideo: Add support for MSI StarCam 370i webcams uvcvideo: Ignore the FIX_BANDWIDTH for compressed video uvcvideo: Return -EINVAL instead of -ENODEV in read() uvcvideo: Fix compilation warning with 2.6.32 due to type mismatch with abs() Two of them are marked as Priority: high and should go to 2.6.32 if possible. uvc_ctrl.c |2 +- uvc_driver.c |9 + uvc_v4l2.c |2 +- uvc_video.c |3 ++- 4 files changed, 13 insertions(+), 3 deletions(-) -- Thanks, 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: [PATCH 5/8] drivers/media/video/uvc: Use %pUl to print UUIDs
On Wed, 2009-11-04 at 15:42 +0100, Laurent Pinchart wrote: Andrew, could you please drop drivers-media-video-uvc-use-%pul-to-print- uuids.patch ? I will push it through the v4l-dvb tree as I need to add backward compatibility support. One thing you might evaluate is how useful it is to continue to support backward compatibility. I think drivers/media is the only drivers directory except staging to continue to use KERNEL_VERSION checks. cheers, Joe -- 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 9/9 v2] mt9t031: make the use of the soc-camera client API optional
Now that we have moved most of the functions over to the v4l2-subdev API, only
quering and setting bus parameters are still performed using the legacy
soc-camera client API. Make the use of this API optional for mt9t031.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
On Mon, 2 Nov 2009, Karicheri, Muralidharan wrote:
+static struct soc_camera_ops mt9t031_ops = {
+ .set_bus_param = mt9t031_set_bus_param,
+ .query_bus_param= mt9t031_query_bus_param,
+ .controls = mt9t031_controls,
+ .num_controls = ARRAY_SIZE(mt9t031_controls),
+};
+
[MK] Why don't you implement queryctrl ops in core? query_bus_param
set_bus_param() can be implemented as a sub device operation as well
right? I think we need to get the bus parameter RFC implemented and
this driver could be targeted for it's first use so that we could
work together to get it accepted. I didn't get a chance to study your
bus image format RFC, but plan to review it soon and to see if it can be
used in my platform as well. For use of this driver in our platform,
all reference to soc_ must be removed. I am ok if the structure is
re-used, but if this driver calls any soc_camera function, it canot
be used in my platform.
Why? Some soc-camera functions are just library functions, you just have
to build soc-camera into your kernel. (also see below)
My point is that the control is for the sensor device, so why to implement
queryctrl in SoC camera? Just for this I need to include SOC camera in
my build? That doesn't make any sense at all. IMHO, queryctrl()
logically belongs to this sensor driver which can be called from the
bridge driver using sudev API call. Any reverse dependency from MT9T031
to SoC camera to be removed if it is to be re-used across other
platforms. Can we agree on this?
In general I'm sure you understand, that there are lots of functions in
the kernel, that we use in specific modules, not because they interact
with other systems, but because they implement some common functionality
and just reduce code-duplication. And I can well imagine that in many such
cases using just one or a couple of such functions will pull a much larger
pile of unused code with them. But in this case those calls can indeed be
very easily eliminated. Please have a look at the version below.
Did you have a chance to compare the driver file that I had sent to you?
I looked at it, but it is based on an earlier version of the driver, so,
it wasn't very easy to compare. Maybe you could send a diff against the
mainline version, on which it is based?
Thanks
Guennadi
drivers/media/video/mt9t031.c | 167 +
1 files changed, 85 insertions(+), 82 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c95c277..86bf8f6 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -204,6 +204,71 @@ static unsigned long mt9t031_query_bus_param(struct
soc_camera_device *icd)
return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
}
+enum {
+ MT9T031_CTRL_VFLIP,
+ MT9T031_CTRL_HFLIP,
+ MT9T031_CTRL_GAIN,
+ MT9T031_CTRL_EXPOSURE,
+ MT9T031_CTRL_EXPOSURE_AUTO,
+};
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
+ [MT9T031_CTRL_VFLIP] = {
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ },
+ [MT9T031_CTRL_HFLIP] = {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ },
+ [MT9T031_CTRL_GAIN] = {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+ .minimum= 0,
+ .maximum= 127,
+ .step = 1,
+ .default_value = 64,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ },
+ [MT9T031_CTRL_EXPOSURE] = {
+ .id = V4L2_CID_EXPOSURE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Exposure,
+ .minimum= 1,
+ .maximum= 255,
+ .step = 1,
+ .default_value = 255,
+ .flags = V4L2_CTRL_FLAG_SLIDER,
+ },
+ [MT9T031_CTRL_EXPOSURE_AUTO] = {
+ .id = V4L2_CID_EXPOSURE_AUTO,
+
RE: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client API optional
Guennadi,
Thanks for the reply. I will have a chance to work on this
sometime in the next two weeks as I am pre-occupied with other
items. I will definitely try to use this version and do my
testing and let you know the result.
Will this apply cleanly to the v4l-dvb linux-next branch?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Wednesday, November 04, 2009 11:49 AM
To: Karicheri, Muralidharan
Cc: Linux Media Mailing List; Hans Verkuil; Laurent Pinchart; Sakari Ailus
Subject: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client
API optional
Now that we have moved most of the functions over to the v4l2-subdev API,
only
quering and setting bus parameters are still performed using the legacy
soc-camera client API. Make the use of this API optional for mt9t031.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
On Mon, 2 Nov 2009, Karicheri, Muralidharan wrote:
+static struct soc_camera_ops mt9t031_ops = {
+.set_bus_param = mt9t031_set_bus_param,
+.query_bus_param= mt9t031_query_bus_param,
+.controls = mt9t031_controls,
+.num_controls = ARRAY_SIZE(mt9t031_controls),
+};
+
[MK] Why don't you implement queryctrl ops in core? query_bus_param
set_bus_param() can be implemented as a sub device operation as well
right? I think we need to get the bus parameter RFC implemented and
this driver could be targeted for it's first use so that we could
work together to get it accepted. I didn't get a chance to study your
bus image format RFC, but plan to review it soon and to see if it can
be
used in my platform as well. For use of this driver in our platform,
all reference to soc_ must be removed. I am ok if the structure is
re-used, but if this driver calls any soc_camera function, it canot
be used in my platform.
Why? Some soc-camera functions are just library functions, you just have
to build soc-camera into your kernel. (also see below)
My point is that the control is for the sensor device, so why to
implement
queryctrl in SoC camera? Just for this I need to include SOC camera in
my build? That doesn't make any sense at all. IMHO, queryctrl()
logically belongs to this sensor driver which can be called from the
bridge driver using sudev API call. Any reverse dependency from MT9T031
to SoC camera to be removed if it is to be re-used across other
platforms. Can we agree on this?
In general I'm sure you understand, that there are lots of functions in
the kernel, that we use in specific modules, not because they interact
with other systems, but because they implement some common functionality
and just reduce code-duplication. And I can well imagine that in many such
cases using just one or a couple of such functions will pull a much larger
pile of unused code with them. But in this case those calls can indeed be
very easily eliminated. Please have a look at the version below.
Did you have a chance to compare the driver file that I had sent to you?
I looked at it, but it is based on an earlier version of the driver, so,
it wasn't very easy to compare. Maybe you could send a diff against the
mainline version, on which it is based?
Thanks
Guennadi
drivers/media/video/mt9t031.c | 167 +
1 files changed, 85 insertions(+), 82 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c95c277..86bf8f6 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -204,6 +204,71 @@ static unsigned long mt9t031_query_bus_param(struct
soc_camera_device *icd)
return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
}
+enum {
+ MT9T031_CTRL_VFLIP,
+ MT9T031_CTRL_HFLIP,
+ MT9T031_CTRL_GAIN,
+ MT9T031_CTRL_EXPOSURE,
+ MT9T031_CTRL_EXPOSURE_AUTO,
+};
+
+static const struct v4l2_queryctrl mt9t031_controls[] = {
+ [MT9T031_CTRL_VFLIP] = {
+ .id = V4L2_CID_VFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Vertically,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ },
+ [MT9T031_CTRL_HFLIP] = {
+ .id = V4L2_CID_HFLIP,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .name = Flip Horizontally,
+ .minimum= 0,
+ .maximum= 1,
+ .step = 1,
+ .default_value = 0,
+ },
+ [MT9T031_CTRL_GAIN] = {
+ .id = V4L2_CID_GAIN,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Gain,
+
still image capture with video preview
linux-media, I previously posted this on the video4linux-list, but linux-media seems a more appropriate place. I am developing on the OMAP3 system using a micron/aptina mt9p031 5-megapixel imager. This CMOs imager supports full image capture (2592x1944 pixels) or you can capture subregions using skipping and binning. We have proven both capabilities, but would like to be able to capture both VGA sized video and still images without using separate drivers. So far, I have not found any support for capturing large images and video through a single driver interface. Does such a capability exist within v4l2? One possible way to solve the problem is to allocate N buffers of the full 5-megapixel size (they end up being 10-MB for each buffer since I'm using 16-bits per pixel), and then using a small portion of that for video. This is less desirable since when I'm capturing video, I only need 640x480 size buffers, and I should only need one snapshot buffer at a time (I'm not streaming them in, just take a snapshot and go back to live video capture). Is there a way to allocate a side-buffer for the 5-megapixel image and also allocate normal sized buffers for video within the same driver? Any recommendations on how to accomplish such a thing? I would think that camera-phones using linux would have run up against this. Thanks, Neil Johnson -- 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
Firedtv stops working after a while
Hi, I have Firedtv DVB-C/CI adapter and for some reason it stops working after a while. Typically it takes something like 5 hours (which makes debugging fun). I have vdr 1.7.9 as the dvb viewer (with xine plugin), kernel 2.6.31 x86_64, latest v4l-dvb drivers from hg and the few remaining patches from firesat.kurelid.se. Vdr spews following to syslog [1]: Nov 4 03:00:42 maxwell vdr: [26241] frontend 0 timed out while tuning to channel 400, tp 266 Nov 4 03:13:35 maxwell vdr: [26242] ERROR: can't set filter (pid=18, tid=40, mask=C0): Input/output error Nov 4 03:13:36 maxwell vdr: [26241] frontend 0 lost lock on channel 180, tp 322 Nov 4 03:13:37 maxwell vdr: [26242] ERROR: can't set filter (pid=0, tid=00, mask=FF): Input/output error Nov 4 03:13:39 maxwell vdr: [26241] frontend 0 timed out while tuning to channel 180, tp 322 Nov 4 03:13:40 maxwell vdr: [26241] frontend 0 regained lock on channel 180, tp 322 Nov 4 03:13:52 maxwell vdr: [26242] ERROR: can't set filter (pid=16, tid=40, mask=FF): Device or resource busy Nov 4 03:13:52 maxwell vdr: [26242] ERROR: can't set filter (pid=3306, tid=02, mask=FF): Device or resource busy Nov 4 03:13:53 maxwell vdr: [26242] ERROR: can't set filter (pid=3306, tid=02, mask=FF): Device or resource busy whereas kernel says [2]: 3[548957.448338] firedtv 0012870036002e6f-0: FCP response timed out 3[548957.448343] firedtv 0012870036002e6f-0: can't set PIDs 4[548974.380505] DVB (dvb_dmxdev_filter_start): could not alloc feed 4[548974.380864] DVB (dvb_dmxdev_filter_start): could not alloc feed + lots of fancy FCP communication debugging thanks to firedtv debug=-1 Kernel-time 548975 corresponds with real time 03:13:35. Computer start was at 1256748240. I had to log kernel messages to separate file so it wouldn't eat all space with syslog files. Trivial workaround is to rmmod firedtv + modprobe firedtv but it is rather annoying. The freeze might be connected to vdr doing EPG scan and trying to check all channels but manually triggering that scan doesn't cause any malfunctions. Any ideas what I should try? 1: http://aketzu.net/firedtv-syslog.bz2 2: http://aketzu.net/firedtv-kmsg.bz2 (206M uncompressed, 14M compressed) -- Anssi Kolehmainen anssi.kolehmai...@iki.fi 040-5085390 -- 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 0/4 v6] Support for TVP7002 in DM365
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client API optional
On Wed, 4 Nov 2009, Karicheri, Muralidharan wrote: Guennadi, Thanks for the reply. I will have a chance to work on this sometime in the next two weeks as I am pre-occupied with other items. I will definitely try to use this version and do my testing and let you know the result. Will this apply cleanly to the v4l-dvb linux-next branch? Maybe you can apply the whole set of 9 patches to it, not sure. Better yet get the complete stack from the location I provided in the introductory mail (0/9) and apply it as instructed there. Just beware, that there are still some older patch versions, which you would have to replace with the ones from this thread. I'll try to update that stack shortly. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/v4l-dvb
Mauro, There was a problem found on the final retail revisions of the Hauppauge WinTV HVR-1150 boards. The fix for this problem is in this merge request. I've tested this with the old revision of the board to ensure that there are no regressions caused by this change. I've included a merge changeset in my repository to ensure that the change in the card configuration setup got applied to the correct card. Please merge this and send to Linus for the rc kernel asap -- I will have to backport this to the stable kernel series. Thank you for acting on my fixups so quickly. This is very helpful -- I really appreciate it. Please pull from: http://kernellabs.com/hg/~mkrufky/v4l-dvb for the following: - saa7134: add support for FORCE_TS_VALID mode for mpeg ts input - saa7134: set ts_force_val for the Hauppauge WinTV HVR-1150 - merge: ~mkrufky/hvr11x0 saa7134-cards.c |2 ++ saa7134-ts.c| 12 saa7134.h |2 ++ 3 files changed, 12 insertions(+), 4 deletions(-) Thanks regards, Mike Krufky -- 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: still image capture with video preview
Hi Neil, Interesting use case. I am thinking of doing the same for vpfe capture drive and here is what I am thinking of doing. 1) sensor driver MT9P031 configures either full capture(2592x1944) (No skipping or binning) and video mode (VGA or 480p or any other resolution through skipping binning) through S_FMT. MT9T031 driver in kernel is doing this already (except for supporting a specific frame rate) and MT9P031 driver may do the same. 2) Application switch the video node between these two modes (video vs still capture) For video (may use 3 or more VGA buffers) using S_FMT, REQBUF, QUERYBUF (optional), mmap (optional) QBUF, STREAMON... When ready for still capture, application do switching to still capture by doing STREAMOFF, S_FMT, REQBUF (use USERPTR), QBUF (one 5M buffer) and STREAMON. When finished, switch back to video again. Here the switching time is critical and to be optimized. BTW, are you planning to send the mt9p031 driver for review? I was looking to see if I can re-use the same in vpfe capture. Also Are you configuring video mode in sensor driver at a specific frame rate? and finally are you using Snapshot mode in sensor for still capture? Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Neil Johnson Sent: Wednesday, November 04, 2009 12:13 PM To: linux-media@vger.kernel.org Subject: still image capture with video preview linux-media, I previously posted this on the video4linux-list, but linux-media seems a more appropriate place. I am developing on the OMAP3 system using a micron/aptina mt9p031 5-megapixel imager. This CMOs imager supports full image capture (2592x1944 pixels) or you can capture subregions using skipping and binning. We have proven both capabilities, but would like to be able to capture both VGA sized video and still images without using separate drivers. So far, I have not found any support for capturing large images and video through a single driver interface. Does such a capability exist within v4l2? One possible way to solve the problem is to allocate N buffers of the full 5-megapixel size (they end up being 10-MB for each buffer since I'm using 16-bits per pixel), and then using a small portion of that for video. This is less desirable since when I'm capturing video, I only need 640x480 size buffers, and I should only need one snapshot buffer at a time (I'm not streaming them in, just take a snapshot and go back to live video capture). Is there a way to allocate a side-buffer for the 5-megapixel image and also allocate normal sized buffers for video within the same driver? Any recommendations on how to accomplish such a thing? I would think that camera-phones using linux would have run up against this. Thanks, Neil Johnson -- 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: [linux-dvb] KWORLD 323U, kernel panic when trying to access ALSA interface
2009/11/4 Marios Andreopoulos opensou...@andmarios.com: Just a small update. After this message of yours: http://www.linuxtv.org/pipermail/linux-dvb/2009-October/032442.html I tried again the v4l-dvb tree and now my card works without problems! I don’t know what the problem was with your tree. I think another tree I had used previously copied it’s modules to a non standard location in /lib/modules/current-kernel/ and thus its modules took precedence over the kernels’, yours’ or v4l-dvb’s modules. It just happened that I upgraded my kernel recently and found out that v4l-dvb works now. Thanks! Well the fix I mentioned for the audio panic was merged on October 29th (and that's the only change that's been made to the driver in five months). This makes me think that perhaps you made some mistake when you tried out the testing tree I sent you. Regardless, it's a relief to hear that it's working for you now, since I didn't have any idea what the problem could be if it wasn't the crash that I fixed. I'll see about getting this backported to stable, since 2.6.31 users are likely to hit this issue as they upgrade to newer distros (such as the recently released Ubuntu 9.10). Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/9] v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera
On Mon, 2 Nov 2009, Karicheri, Muralidharan wrote: @@ -301,9 +301,9 @@ static int mt9t031_set_params(struct soc_camera_device *icd, ret = reg_write(client, MT9T031_WINDOW_WIDTH, rect-width - 1); if (ret = 0) ret = reg_write(client, MT9T031_WINDOW_HEIGHT, - rect-height + icd-y_skip_top - 1); + rect-height - 1); Why y_skip_top is removed? Because noone ever said they needed it? I suggest you keep it. It can have default 0. I have not viewed the resulting image for the top line to see if it is corrupted. I just use it to display it to my display device and I am not seeing any corruption. I need to view the image at some point to check if it has any corruption. Ok, I preserved it, although I'm not convinced it is indeed needed. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pxa_camera + mt9m1111: image shifted (was: Failed to configure for format 50323234)
On Tue, 3 Nov 2009, Antonio Ospite wrote: On Mon, 05 Oct 2009 08:32:10 +0200 Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de wrote: Antonio Ospite schrieb: On Sun, 4 Oct 2009 00:31:24 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Anyways your patch works, but the picture is now shifted, see: http://people.openezx.org/ao2/a780-pxa-camera-mt9m111-shifted.jpg Is this because of the new cropping code? Hm, it shouldn't be. Does it look always like this - reproducible? What program are you using? What about other geometry configurations? Have you ever seen this with previous kernel versions? New cropping - neither mplayer nor gstreamer use cropping normally. This seems more like a HSYNC problem to me. Double-check platform data? Is it mioa701 or some custom board? Platform data: if I set SOCAM_HSYNC_ACTIVE_HIGH the result is even wronger, with or without SOCAM_HSYNC_ACTIVE_LOW I get the same result, now reproducible, see below. Only for your information. Maybe it helps to reproduce the error. I have the same problem with my own ov9655 driver on a pxa platform since I update to kernel 2.6.30 and add crop support. Every first open of the camera after system reset the image looks like yours. If I use the camera the next time without changing the resolution everything is OK. Only during the first open the resolution of the camera is changed and function fmt set in the ov9655 driver is called twice. I use the camera with my one program and it doesn't use crop. Thanks Stefan, now I can reproduce the problem. 1. Boot the system 2. Capture an image with capture-example from v4l2-apps. Then I have the shift as in the picture above on the *first* device open, if I open the device again and capture a second time, without rebooting, the picture is fine. I'll let you know if I find more clues of what is causing this behavior. Yes, please do. I'll try to find some time to double-check this with my setup. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: still image capture with video preview
Hi Murali, On Wed, Nov 4, 2009 at 11:31 AM, Karicheri, Muralidharan m-kariche...@ti.com wrote: Hi Neil, Interesting use case. I am thinking of doing the same for vpfe capture drive and here is what I am thinking of doing. I started my testing with the DaVinci 6446 (using the DVEVM from TI), using the LeopardImaging add-on board, but we made a hardware switch to the OMAP3530 because of its size and low-heat characteristics. I've been trying to leverage existing code on the DaVinci when possible, but the drivers have diverged a bit. (especially in the VPFE vs Camera ISP) 1) sensor driver MT9P031 configures either full capture(2592x1944) (No skipping or binning) and video mode (VGA or 480p or any other resolution through skipping binning) through S_FMT. MT9T031 driver in kernel is doing this already (except for supporting a specific frame rate) and MT9P031 driver may do the same. At this point I have hard-coded the kernel to either do full capture or VGA/480P-sized capture. I've been able to take full-sized still images when the kernel is configured that way (camera isp and sensor must both be configured). I can also compile the kernel such that I capture 30 fps VGA or 480P (both isp and sensor configured again). However, when I configure the kernel to capture full-sized images (2592x1944), the isp gets configured upon the call to open(), so the previewer/resizer buffers are huge. Then, I can configure the sensor to capture at a smaller resolution, but the frame rate gets reduced to about 5 fps. Ideally, I wouldn't allocate such large buffers if I were just capturing video. I may be doing something wrong with the sensor configuration, so I'm exploring that. 2) Application switch the video node between these two modes (video vs still capture) For video (may use 3 or more VGA buffers) using S_FMT, REQBUF, QUERYBUF (optional), mmap (optional) QBUF, STREAMON... When ready for still capture, application do switching to still capture by doing STREAMOFF, S_FMT, REQBUF (use USERPTR), QBUF (one 5M buffer) and STREAMON. When finished, switch back to video again. Here the switching time is critical and to be optimized. I'm considering this, too. However, up to this point, all my attempts to use USERPTR have failed. I need to revisit that and see where exactly it's failing and why. I'm not sure that my driver fully supports it, and the documentation on USERPTR has been a bit scarce, so I may not be doing it properly. BTW, are you planning to send the mt9p031 driver for review? I was looking to see if I can re-use the same in vpfe capture. My kernel source tree is a bit of an amalgamation from a variety of sources. So, it doesn't lend itself well to creating a patch and sending it upstream for review. What base should I work off of so that I can submit a good patch? Also Are you configuring video mode in sensor driver at a specific frame rate? and finally are you using Snapshot mode in sensor for still capture? I have tuned the vertical and horizontal blanking to output 720x480 at 30 fps. I am using the OMAP-generated cam_clk at 36 MHz. I have done some experimentation using snapshot mode, but only to test that a mechanical shutter opens and closes based on strobe pulses, not actually capturing mechanically-shuttered images yet...hopefully I'll be doing that soon. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Neil Johnson Sent: Wednesday, November 04, 2009 12:13 PM To: linux-media@vger.kernel.org Subject: still image capture with video preview linux-media, I previously posted this on the video4linux-list, but linux-media seems a more appropriate place. I am developing on the OMAP3 system using a micron/aptina mt9p031 5-megapixel imager. This CMOs imager supports full image capture (2592x1944 pixels) or you can capture subregions using skipping and binning. We have proven both capabilities, but would like to be able to capture both VGA sized video and still images without using separate drivers. So far, I have not found any support for capturing large images and video through a single driver interface. Does such a capability exist within v4l2? One possible way to solve the problem is to allocate N buffers of the full 5-megapixel size (they end up being 10-MB for each buffer since I'm using 16-bits per pixel), and then using a small portion of that for video. This is less desirable since when I'm capturing video, I only need 640x480 size buffers, and I should only need one snapshot buffer at a time (I'm not streaming them in, just take a snapshot and go back to live video capture). Is there a way to allocate a side-buffer for the 5-megapixel image and also allocate normal sized buffers for video within the same driver? Any recommendations on how to
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 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:Wed Nov 4 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13284:b8282a1720c4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-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-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc3-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc3-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-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK 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: WARNINGS 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: WARNINGS 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] gspca pac7302/pac7311: handle return value of usb_control_msg()
From: Márton Németh nm...@freemail.hu
The function usb_control_msg() can return error any time so at least
warn the user if an error happens. No message is printed in case of
normal operation.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r e628f4381170 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Mon Nov 02 14:00:48 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Wed Nov 04 23:30:53 2009 +0100
@@ -335,27 +335,40 @@
__u8 index,
const char *buffer, int len)
{
+ int ret;
+
memcpy(gspca_dev-usb_buf, buffer, len);
- usb_control_msg(gspca_dev-dev,
+ ret = usb_control_msg(gspca_dev-dev,
usb_sndctrlpipe(gspca_dev-dev, 0),
1, /* request */
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, /* value */
index, gspca_dev-usb_buf, len,
500);
+ if (ret 0)
+ PDEBUG(D_ERR, reg_w_buf():
+ Failed to write registers to index 0x%x, error %i,
+ index, ret);
}
#if 0 /* not used */
static __u8 reg_r(struct gspca_dev *gspca_dev,
__u8 index)
{
- usb_control_msg(gspca_dev-dev,
+ int ret;
+
+ ret = usb_control_msg(gspca_dev-dev,
usb_rcvctrlpipe(gspca_dev-dev, 0),
0, /* request */
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, /* value */
index, gspca_dev-usb_buf, 1,
500);
+ if (ret 0)
+ PDEBUG(D_ERR, reg_r():
+ Failed to read register from index 0x%x, error %i,
+ index, ret);
+
return gspca_dev-usb_buf[0];
}
#endif
@@ -364,13 +377,19 @@
__u8 index,
__u8 value)
{
+ int ret;
+
gspca_dev-usb_buf[0] = value;
- usb_control_msg(gspca_dev-dev,
+ ret = usb_control_msg(gspca_dev-dev,
usb_sndctrlpipe(gspca_dev-dev, 0),
0, /* request */
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, gspca_dev-usb_buf, 1,
500);
+ if (ret 0)
+ PDEBUG(D_ERR, reg_w():
+ Failed to write register to index 0x%x, value 0x%x, error %i,
+ index, value, ret);
}
static void reg_w_seq(struct gspca_dev *gspca_dev,
@@ -387,17 +406,23 @@
const __u8 *page, int len)
{
int index;
+ int ret;
for (index = 0; index len; index++) {
if (page[index] == SKIP)/* skip this index */
continue;
gspca_dev-usb_buf[0] = page[index];
- usb_control_msg(gspca_dev-dev,
+ ret = usb_control_msg(gspca_dev-dev,
usb_sndctrlpipe(gspca_dev-dev, 0),
0, /* request */
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, gspca_dev-usb_buf, 1,
500);
+ if (ret 0)
+ PDEBUG(D_ERR, reg_w_page():
+ Failed to write register to index 0x%x,
+ value 0x%x, error %i,
+ index, page[index], ret);
}
}
diff -r e628f4381170 linux/drivers/media/video/gspca/pac7311.c
--- a/linux/drivers/media/video/gspca/pac7311.c Mon Nov 02 14:00:48 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7311.c Wed Nov 04 23:30:53 2009 +0100
@@ -263,27 +263,40 @@
__u8 index,
const char *buffer, int len)
{
+ int ret;
+
memcpy(gspca_dev-usb_buf, buffer, len);
- usb_control_msg(gspca_dev-dev,
+ ret = usb_control_msg(gspca_dev-dev,
usb_sndctrlpipe(gspca_dev-dev, 0),
1, /* request */
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, /* value */
index, gspca_dev-usb_buf, len,
500);
+ if (ret 0)
+ PDEBUG(D_ERR, reg_w_buf():
+ Failed to write registers to index 0x%x, error %i,
+ index, ret);
}
#if 0 /* not used */
static __u8 reg_r(struct gspca_dev *gspca_dev,
__u8 index)
{
- usb_control_msg(gspca_dev-dev,
+ int ret;
+
+ ret = usb_control_msg(gspca_dev-dev,
usb_rcvctrlpipe(gspca_dev-dev, 0),
0, /* request */
Re: [PATCH 5/6] mx31moboard: camera support
Guennadi Liakhovetski wrote: On Tue, 3 Nov 2009, Valentin Longchamp wrote: Hi Guennadi, Valentin Longchamp wrote: Guennadi Liakhovetski wrote: 3. to support switching inputs, significant modifications to soc_camera.c would be required. I read Nate's argument before, that as long as clients can only be accessed one at a time, this should be presented by multiple inputs rather than multiple device nodes. Somebody else from the V4L folk has also confirmed this opinion. In principle I don't feel strongly either way. But currently soc-camera uses a one i2c client to one device node model, and I'm somewhat reluctant to change this before we're done with the v4l2-subdev conversion. Sure, one step at a time. So for now the switching is not possible with soc_camera. My problem is that both cameras have the same I2C address since they are the same. Would I need to declare 2 i2c_device with the same address (I'm not sure it would even work ...) used by two _client_ platform_devices or would I have to have the two platform devices pointing to the same i2c_device ? I've finally had time to test all this. My current problem with registering the two cameras is that they both have the same i2c address, and soc_camera calls v4l2_i2c_new_subdev_board where in my case the same address on the same i2c tries to be registered and of course fails. We would need a way in soc_camera not to register a new i2c client for device but use an existing one (but that's what you don't want to change for now as you state it in your above last sentence). I just want to point this out once more so that you know there is interest about this for the next soc_camera works. These are two separate issues: inability to work with two devices with the same i2c address, and arguably suboptimal choice of the way to switch between multiple mutually-exclusive clients (sensors) on a single interface. For multiple chips with the same adderess, in principle you could register one or more video devices yet before registering respective i2c devices. And then on the selected switching operation (either opening of one of the /dev/video* nodes, or selecting an input) you register the i2c device, probe it, etc. This would work, but looks seriously overengineered to me. And it would indeed require pretty fundamental changes to the soc-camera core. Yeah I had noticed that this was possible by not calling i2c_register_device (or some like that) is soc_camera.c and give the i2c device directly to the soc_camera client device init method, but since this requires changes in the soc_camera core code that you are currently heavily modifying, I did not find it usefull. Otherwise we could push this switching down into the driver / platform. We could just export only one camera from the platform code, implement a S_INPUT method in soc-camera, that would be delivered to the sensor driver, it would save context of the current sensor, call the platform hook to switch to another camera, and restore its configuration. In this case the soc-camera core and the host driver would not see two sensors, but just one, all the switching would be done internally in the sensor driver / platform callback. If we also decide to use S_INPUT to switch between different sensors on an interface, we would have to make a distinction between two cases in the core - whether the input we're switching to belongs to the same sensor or to another one. Leaving the the camera switch to platform code looks very important to me. Having only one camera exported looks fine to me, especially since I have both cameras the same (but I don't think it would be possible with two different sensors ?). But I don't know v4l2 API well enough to see when it would be used to switch to an input on the same physical sensor. So my current solution for mainline inclusion is to register only one camera device node without taking care of the cam mux for now. Yes, please, send me an updated version of the patch. I think, you haven't done that yet, right? I have the updated version, I have however forgotten to add you in the recipient list, have a look on the arm-mailing-list: http://article.gmane.org/gmane.linux.ports.arm.kernel/68123 Thanks for all your comments Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEA3485, Station 9, CH-1015 Lausanne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Struggling with Astra 2D (Freesat) / Happauage Nova-HD-S2
Replying to myself is the first sign that I need to be committed to a mental institution. So here goes. On Wed, 4 Nov 2009, BOUWSMA Barry wrote: The other possibility, given that two of the four inputs to your multiswitch work, is that the two low-band inputs have been crossed. Thinking more about this, I don't think this is the case, if someone hasn't already corrected me -- there is a range of frequencies which, last time I scanned, were shared by both polarisations, with identical symbol rates. Although this was not legitimate input for an earlier `scan' and I've hacked a script to work around this. ### frequency pairs, h+v, mostly 27500 from 11200 upwards S 11222170 H 27500 S 11223670 V 27500 # S 11259670 V 27500 This has an odd SR NO MORE... S 11264470 H 22000 S 11261170 H 27500 # S 11307000 V 27500 S 11307000 H 27500 # S 11343000 V 27500 This has an odd SR NO MORE... S 11344000 H 22000 S 11344500 H 27500 # S 11388830 H 27500 S 11390330 V 27500 This continues, more or less, through 11500. In other words, if your two low-band inputs to the multiswitch were reversed, you'd still get something on the above frequencies, even if the actual parameters you'd be reading wouldn't match what is actually transmitted. Sorry for the misleading info I posted earlier. If there is any cabling problem, I'm positive it would have been noted as the BBC channels are certain to be ones checked by any halfway competent technician. As far as the possibility that your tuner card isn't properly switching into low-band, if you were to modify your scan file so that the successfully-tuned frequencies above 11700 are repeated but with a value corresponding to the different IF frequency, and you can again receive the same services, then that would point to that problem. I'd give an example, but that would require me to think. But here's the idea -- if you've tuned 11720, that's with an IF of 10600. With an IF of 9750, you'd want to be tuning to 11720 - (10600-9750) MHz. If that makes any sense. thanks, barry bouwsma -- 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: MSI StarCam Racer - No valid video chain found
Hi Laurent, I send you log file with trace (kernel 2.6.30.9) I have tried this kernel (on UBNT RouterStation and OpenWrt) with results: 2.6.28.10. - camera works, I tried only snapshots (I have to use external power for USB, without external power sometimes works, sometimes no ...) 2.6.31.5 - kernel copmpiles ok, but uvcvideo module was missing, I don't know why ... Thanks, Martin Laurent Pinchart napsal(a): Hi Martin, On Monday 02 November 2009 21:31:50 Martin Rod wrote: Hi Laurent, I send you output of lsusb. I think, that the uvcdriver is the latest. I try older kernel tomorrow. Could you please load the driver with trace=255 (modprobe uvcvideo trace=255) or, if the driver is already loaded, change the trace parameter to 255 (echo 255 /sys/module/uvcvideo/parameters/trace), plug your camera and send me the messages printed by the uvcvideo driver to the kernel log? Thanks. usb 1-1: USB disconnect, address 3 usb 1-1: new high speed USB device using ar71xx-ehci and address 4 usb 1-1: configuration #1 chosen from 1 choice uvcvideo: Probing generic UVC device 1 uvcvideo: Found format YUV 4:2:2 (YUYV). uvcvideo: - 640x480 (30.0 fps) uvcvideo: - 352x288 (30.0 fps) uvcvideo: - 320x240 (30.0 fps) uvcvideo: - 176x144 (30.0 fps) uvcvideo: - 160x120 (30.0 fps) uvcvideo: device 4 videostreaminginterface 1 frame index 9 out of range uvcvideo: Found a Status endpoint (addr 83). uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:62e0) uvcvideo: Added control ----0101/2 to device 1 entity 3 uvcvideo: Added control ----0101/3 to device 1 entity 3 uvcvideo: Added control ----0101/6 to device 1 entity 3 uvcvideo: Added control ----0101/7 to device 1 entity 3 uvcvideo: Added control ----0101/8 to device 1 entity 3 uvcvideo: Added control ----0101/9 to device 1 entity 3 uvcvideo: Added control ----0101/10 to device 1 entity 3 uvcvideo: Added control ----0101/1 to device 1 entity 3 uvcvideo: Added control ----0101/4 to device 1 entity 3 uvcvideo: Added control ----0101/5 to device 1 entity 3 uvcvideo: Added control ----0101/11 to device 1 entity 3 uvcvideo: Added control ----0001/2 to device 1 entity 1 uvcvideo: Added control ----0001/3 to device 1 entity 1 uvcvideo: Added control ----0001/4 to device 1 entity 1 uvcvideo: Added control ----0001/11 to device 1 entity 1 uvcvideo: Added control ----0001/13 to device 1 entity 1 uvcvideo: Scanning UVC chain: OT 2 - XU 5 - XU 4 - PU 3 - IT 1 uvcvideo: No valid video chain found.
Re: Patch for Leadtek Winfast TV USB II Deluxe (with IR)
Hi Magnus,
Em Thu, 29 Oct 2009 14:41:15 +0100
Magnus Alm magnus@gmail.com escreveu:
Hi!
I managed to get the remote working now in both in Ubuntu 9.04 (kernel
2.6.28-16) and Ubuntu 9.10 (kernel 2.6.31-14).
There is one difference tho, in the 2.6.28-16 kernel the remote
doesn't do anything without configuring lirc.
In 2.6.31-14 I can for example adjust volume in X and use the numeric
keys to change channels in tvtime without lirc.
Don't know why, it just works like that.
I've added 3 different examples for a patch as attachment, since the
remote can be enabled different ways.
(They also changes the basic config for my board.)
ex1.patch only works for kernel 2.6.31.
ex2.patch works for both 2.6.31 and 2.6.28 but can in the future cause
problems for boards that would like to use adress 0x1f (0x3e) for IR.
(Because of the case 0x1f for my board.)
ex3.patch is a combination of ex1 and ex2. where it is depending on if
kernel version is higher or lower than 2.6.30.
Dunno which one that would be most suitable.
The better is to follow what's specified at the InfraRed section of the API
spec:
http://www.linuxtv.org/downloads/v4l-dvb-apis/ch17.html
It is up to the userspace apps to adopt the standard.
Also, you can easily replace the table at userspace or use lirc.
Another thing is that my board finds an IR device at 0x18 (0x30), but
ir-polling doesn't work at that address, so if any board in the future
needs that added
0x1f needs to stand before 0x18.
This is for the funtion in em28xx-cards if kernel higher than 2.6.30:
const unsigned short addr_list[] = {
0x1f, 0x30, 0x47, I2C_CLIENT_END
};
or in ir-kbd-i2c for kernel lower than 2.6.30:
static const int probe_em28XX[] = { 0x1f, 0x30, 0x47, -1 };
Please send a patch for it.
I guess you also might have objections in how I'm naming stuff like
get_key_lwtu2d, maybe it's a bit obscure...
Yes, it is. Please choose a better name ;)
Also, please don't add two separate functions (one for 2.6.30 or lower and
another for upper kernels).
The most important thing is to send the patches at -p1 format, and to send
your Signed-off-by. Please read
http://www.linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches
For more info about how to submit a patch.
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: [PATCH/RFC 9/9 v2] mt9t031: make the use of the soc-camera client API optional
On Wed, 4 Nov 2009, Guennadi Liakhovetski wrote: On Wed, 4 Nov 2009, Karicheri, Muralidharan wrote: Guennadi, Thanks for the reply. I will have a chance to work on this sometime in the next two weeks as I am pre-occupied with other items. I will definitely try to use this version and do my testing and let you know the result. Will this apply cleanly to the v4l-dvb linux-next branch? Maybe you can apply the whole set of 9 patches to it, not sure. Better yet get the complete stack from the location I provided in the introductory mail (0/9) and apply it as instructed there. Just beware, that there are still some older patch versions, which you would have to replace with the ones from this thread. I'll try to update that stack shortly. The current stack, based on 2.6.32-rc5, is at http://download.open-technology.de/soc-camera/20091105/ Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
