Re: CEU / Camera Driver Question
Hi Charles On Tue, 13 Apr 2010, Charles D. Krebs wrote: Guennadi, Thank you for the response and explanation. It falls perfectly in line with what we had been suspecting on our end. We ended up basing the driver off mt9t112.c, which is an I2C camera. The major issues have been figuring out how to remove the I2C components. The driver (attached for reference) currently registers a device under /sys/bus/platform/drivers/testcam. However, udev does not populate a video0 entry under /dev, so it seems the V4L2 registration wasn't done correctly. All my comments will base on the current kernel, so, if you prefer to stay with an older one, they will not be (entirely) applicable. I'm fairly sure the problem falls under testcam_probe or testcam_module_init. Since we are not I2C, should we call platform_driver_register from testcam_module_init? Do we need to fill out a link structure from the SOC Camera driver (soc_camera_link)? I noticed that this is used in all the I2C cameras. As I see, your driver is just a dummy, that only specifies camera's capabilities. That's also ok, you certainly can make a driver for a completely fixed-parameter camera, but then a few methods from your driver should either disappear, or return an unsupported error, or return the fixed configuration of the sensor (like s_fmt, try_fmt). Please, have a look at drivers/media/video/soc_camera_platform.c, that's an example of an soc-camera client driver, not using i2c. I'm not sure if it's working presently, it's use kind of discouraged, but you can certainly use it as an example. If you don't plan to mainline your driver, you can even actually use soc_camera_platform.c, then you'll just need to add some platform data for it (see arch/sh/boards/mach-ap325rxa/setup.c and struct soc_camera_link camera_link in it for an example). You might have to fix that driver slightly, but that shouldn't be too difficult. Thanks Guennadi Unfortunately, I still need to figure out how to best integrate with the sh_mobile_ceu_camera driver since I am mid migration from 2.6.31-rc7 to 2.6.33. It appears that quite a lot has changed... The Kernel change has spawned a plethora of issues, which has unfortunately delayed development on this driver until now. Thanks for your input! Charles Krebs, Embedded Solutions Developer The Realtime Group -- From: Guennadi Liakhovetski g.liakhovet...@gmx.de Sent: Thursday, April 08, 2010 1:39 AM To: Magnus Damm magnus.d...@gmail.com Cc: Charles D. Krebs ckr...@therealtimegroup.com Subject: Re: CEU / Camera Driver Question Hi Charles On Thu, 8 Apr 2010, Magnus Damm wrote: Hi Charles, Thanks for your email. I am afraid I know too little about the current status of the CEU driver and camera sensor integration. I do however know one guy that can help you. Guennadi, can you please give us some recommendations? Charles is using 2.6.33 on sh7724, see below. Thanks! / magnus On Apr 6, 2010 10:35 AM, Charles D. Krebs ckr...@therealtimegroup.com wrote: Magnus, We have been working on integrating our camera into the 7724 platform. I think we are pretty close to having the camera up and working at this point, but there are a few outstanding concerns. In the open-source community it is customary to discuss related topics and ask questions on respective mailing lists. So, I'll just give a very brief answer to this your mail, if you get more questions, please CC Linux Media Mailing List linux-media@vger.kernel.org in your naxt mail. The basic objective is to interface a very dumb video camera that connects directly to CEU driver in the SH7724 processor. This camera needs no control interface (the interface is actually RS232, which I plan to drive completely from user space), but has 8 bit parallel video (Grayscale). The camera driver was patterned after the the soc_camera driver, using the platform interface. Our camera driver is mostly dummy code because of the simplicity. The current Linux kernel mainline implementation of the video capture function on several embedded SoCs, including CEU-based SuperH platforms, is a V4L2 driver stack, consisting of 1. a host driver (in this case sh_mobile_ceu_camera.c), using the soc-camera API to integrate itself into the V4L framework 2. the soc-camera core 3. client drivers, using the v4l2-subdev API for most V4L2 communication, the mediabus API for pixel-format negotiation and a couple of soc-camera API extensions. So, all you need is use the existing sh_mobile_ceu_camera.c driver, the soc-camera framework and add a new driver for your camera-sensor, which in your case would be very simple, as you say. Just use any platform, currently in the mainline (e.g., ecovec) as an example for your platform bindings, and any
[PATCH] tm6000, moving cards name defines
Hi
Move TV cards name defines to better place header file.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Mon Apr 05 22:56:43
2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Wed Apr 14 11:18:03
2010 +1000
@@ -35,22 +35,6 @@
#include tuner-xc2028.h
#include xc5000.h
-#define TM6000_BOARD_UNKNOWN 0
-#define TM5600_BOARD_GENERIC 1
-#define TM6000_BOARD_GENERIC 2
-#define TM6010_BOARD_GENERIC 3
-#define TM5600_BOARD_10MOONS_UT821 4
-#define TM5600_BOARD_10MOONS_UT330 5
-#define TM6000_BOARD_ADSTECH_DUAL_TV 6
-#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
-#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
-#define TM6010_BOARD_HAUPPAUGE_900H9
-#define TM6010_BOARD_BEHOLD_WANDER 10
-#define TM6010_BOARD_BEHOLD_VOYAGER11
-#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
-#define TM6010_BOARD_TWINHAN_TU501 13
-
-#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
module_param_array(card, int, NULL, 0444);
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000.h
--- a/linux/drivers/staging/tm6000/tm6000.h Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000.h Wed Apr 14 11:18:03 2010 +1000
@@ -41,6 +41,23 @@
#include dmxdev.h
#define TM6000_VERSION KERNEL_VERSION(0, 0, 2)
+
+#define TM6000_BOARD_UNKNOWN 0
+#define TM5600_BOARD_GENERIC 1
+#define TM6000_BOARD_GENERIC 2
+#define TM6010_BOARD_GENERIC 3
+#define TM5600_BOARD_10MOONS_UT821 4
+#define TM5600_BOARD_10MOONS_UT330 5
+#define TM6000_BOARD_ADSTECH_DUAL_TV 6
+#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
+#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
+#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
+#define TM6010_BOARD_TWINHAN_TU501 13
+
+#define TM6000_MAXBOARDS16
/* Inputs */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Wed Apr 14 11:18:03 2010 +1000
@@ -35,22 +35,6 @@
#include tuner-xc2028.h
#include xc5000.h
-#define TM6000_BOARD_UNKNOWN 0
-#define TM5600_BOARD_GENERIC 1
-#define TM6000_BOARD_GENERIC 2
-#define TM6010_BOARD_GENERIC 3
-#define TM5600_BOARD_10MOONS_UT821 4
-#define TM5600_BOARD_10MOONS_UT330 5
-#define TM6000_BOARD_ADSTECH_DUAL_TV 6
-#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
-#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
-#define TM6010_BOARD_HAUPPAUGE_900H 9
-#define TM6010_BOARD_BEHOLD_WANDER 10
-#define TM6010_BOARD_BEHOLD_VOYAGER 11
-#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
-#define TM6010_BOARD_TWINHAN_TU501 13
-
-#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
module_param_array(card, int, NULL, 0444);
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000.h
--- a/linux/drivers/staging/tm6000/tm6000.h Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000.h Wed Apr 14 11:18:03 2010 +1000
@@ -41,6 +41,23 @@
#include dmxdev.h
#define TM6000_VERSION KERNEL_VERSION(0, 0, 2)
+
+#define TM6000_BOARD_UNKNOWN 0
+#define TM5600_BOARD_GENERIC 1
+#define TM6000_BOARD_GENERIC 2
+#define TM6010_BOARD_GENERIC 3
+#define TM5600_BOARD_10MOONS_UT821 4
+#define TM5600_BOARD_10MOONS_UT330 5
+#define TM6000_BOARD_ADSTECH_DUAL_TV 6
+#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
+#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
+#define TM6010_BOARD_HAUPPAUGE_900H 9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER 11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE 12
+#define TM6010_BOARD_TWINHAN_TU501 13
+
+#define TM6000_MAXBOARDS16
/* Inputs */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
Re: mantis crashes
I have the exact same symptoms with a technisat cablestar HD2, also a twinhan clone like the terratec. Glad to know this isn't a broken hardware issue (that is it seems highly unlikely we have the exact same problem for it to be a hardware malfunction ). Have used the .31 and .32 and .33 kernel in ubuntu under karmic and lucid. With a own compiled mantis driver from intuxication and linuxtv mercurial repos. So it kinda looks like this is a ubuntu thing? Or are there alternative conclusions? Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mantis crashes
On Wed, Apr 14, 2010 at 11:41:18AM +, hans van den Bogert wrote: I have the exact same symptoms with a technisat cablestar HD2, also a twinhan clone like the terratec. Glad to know this isn't a broken hardware issue (that is it seems highly unlikely we have the exact same problem for it to be a hardware malfunction ). Have used the .31 and .32 and .33 kernel in ubuntu under karmic and lucid. With a own compiled mantis driver from intuxication and linuxtv mercurial repos. I have been trying since Hardy :) Always the same. Also tried the jusst.de and s2-liplianin trees back and forth ever since. But I have met users with the same clone card and same Ubuntu who had no issues. Looks like I will be able to try an identical card very soon. I'll let you know how that works out. So it kinda looks like this is a ubuntu thing? Or are there alternative conclusions? Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Vidar Tyldum Hansen vi...@tyldum.com PGP: 0x3110AA98 -- 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] mt9t031: preserve output format on VIDIOC_S_CROP
Interpretation of the V4L2 API specification, according to which the
VIDIOC_S_CROP ioctl for capture devices shall set the input window and
preserve the scales, thus possibly changing the output window, seems to be
incorrect. Switch to using a more intuitive definition, i.e., to
preserving the output format while changing scales.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Val, I do not have any mt9t031 hardware any more, could you, please, test
this patch and verify, that it does indeed do, what's described above?
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index a9061bf..a604fa0 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -63,6 +63,8 @@
struct mt9t031 {
struct v4l2_subdev subdev;
struct v4l2_rect rect; /* Sensor window */
+ unsigned int out_width;
+ unsigned int out_height;
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
u16 xskip;
u16 yskip;
@@ -284,6 +286,26 @@ static u16 mt9t031_skip(s32 *source, s32 target, s32 max)
return skip;
}
+static u16 mt9t031_skip_out(s32 *source, s32 *target)
+{
+ unsigned int skip;
+
+ if (*source *target + *target / 2) {
+ *target = *source;
+ return 1;
+ }
+
+ skip = (*source + *target / 2) / *target;
+ if (skip 8) {
+ skip = 8;
+ *target = (*source + 4) / 8;
+ }
+ /* We try to preserve input, but with division we have to adjust it too
*/
+ *source = *target * skip;
+
+ return skip;
+}
+
/* rect is the sensor rectangle, the caller guarantees parameter validity */
static int mt9t031_set_params(struct i2c_client *client,
struct v4l2_rect *rect, u16 xskip, u16 yskip)
@@ -393,6 +415,7 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
struct v4l2_rect rect = a-c;
struct i2c_client *client = sd-priv;
struct mt9t031 *mt9t031 = to_mt9t031(client);
+ u16 xskip, yskip;
rect.width = ALIGN(rect.width, 2);
rect.height = ALIGN(rect.height, 2);
@@ -403,7 +426,10 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
soc_camera_limit_side(rect.top, rect.height,
MT9T031_ROW_SKIP, MT9T031_MIN_HEIGHT, MT9T031_MAX_HEIGHT);
- return mt9t031_set_params(client, rect, mt9t031-xskip,
mt9t031-yskip);
+ xskip = mt9t031_skip_out(rect.width, mt9t031-out_width);
+ yskip = mt9t031_skip_out(rect.height, mt9t031-out_height);
+
+ return mt9t031_set_params(client, rect, xskip, yskip);
}
static int mt9t031_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
@@ -437,8 +463,8 @@ static int mt9t031_g_fmt(struct v4l2_subdev *sd,
struct i2c_client *client = sd-priv;
struct mt9t031 *mt9t031 = to_mt9t031(client);
- mf-width = mt9t031-rect.width / mt9t031-xskip;
- mf-height = mt9t031-rect.height / mt9t031-yskip;
+ mf-width = mt9t031-out_width;
+ mf-height = mt9t031-out_height;
mf-code= V4L2_MBUS_FMT_SBGGR10_1X10;
mf-colorspace = V4L2_COLORSPACE_SRGB;
mf-field = V4L2_FIELD_NONE;
@@ -455,8 +481,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
struct v4l2_rect rect = mt9t031-rect;
/*
-* try_fmt has put width and height within limits.
-* S_FMT: use binning and skipping for scaling
+* try_fmt has put width and height within limits. Note: when converting
+* to a generic v4l2-subdev driver, try_fmt will have to be called
+* explicitly. S_FMT: use binning and skipping for scaling.
*/
xskip = mt9t031_skip(rect.width, mf-width, MT9T031_MAX_WIDTH);
yskip = mt9t031_skip(rect.height, mf-height, MT9T031_MAX_HEIGHT);
@@ -464,6 +491,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
mf-code= V4L2_MBUS_FMT_SBGGR10_1X10;
mf-colorspace = V4L2_COLORSPACE_SRGB;
+ mt9t031-out_width = mf-width;
+ mt9t031-out_height = mf-height;
+
/* mt9t031_set_params() doesn't change width and height */
return mt9t031_set_params(client, rect, xskip, yskip);
}
@@ -807,6 +837,9 @@ static int mt9t031_probe(struct i2c_client *client,
mt9t031-rect.width = MT9T031_MAX_WIDTH;
mt9t031-rect.height= MT9T031_MAX_HEIGHT;
+ mt9t031-out_width = MT9T031_MAX_WIDTH;
+ mt9t031-out_height = MT9T031_MAX_HEIGHT;
+
/*
* Simulated autoexposure. If enabled, we calculate shutter width
* ourselves in the driver based on vertical blanking and frame width
--
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
cx5000 default auto sleep mode
Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. -- 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: cx5000 default auto sleep mode
On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz tl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. The xc5000 power management changes I made were actually pretty thoroughly tested with that card (between myself and Michael Krufky, we tested it with just about every card that uses the tuner). In fact, we uncovered several power management bugs in other drivers as a result of that effort. It was a grueling effort that I spent almost three months working on. Generally I agree with the premise that functionality like this should only be enabled for boards it was tested with. However, in this case it actually was pretty extensively tested with all the cards in question (including this one), and thus it was deemed safe to enable by default. We've had cases in the past where developers exercised poor judgement and blindly turned on power management to make it work with one card, disregarding the possible breakage that could occur with other cards that use the same driver -- this was *not* one of those cases. If there is a bug, it should be pretty straightforward to fix provided it can be reproduced. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? 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: tm6000: firmware
Hi Stefan, Em 14-04-2010 09:26, Stefan Ringel escreveu: Hi Mauro, Can you added these three firmwares? The third is into archive file, because I'm extracted for an user (Bee Hock Goh). Sorry, but for us to put the firmwares at the server and/or add them at linux-firmware git tree, we need to get the distribution rights from the manufacturer, as described on: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission So, we need Xceive's ack, in order to add the firmware files somewhere. That's why currently we're using the procedure described on the comments at the extraction tool: Documentation/video4linux/extract_xc3028.pl 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: Info
Hi Devin, ...do you think we will have our stick (0072/terratec hybrid xs fm) working before FIFA World Cup? Thanks Adriano Il 14/02/2010 18:33, Florent NOUVELLON ha scritto: Hi Devin, Did you with Prahal advanced the 0072/terratec hybrid xs fm support in linux-dvb driver ? If you need any kind of help (testing, or whatever) feel free to ask me. Regards, Florent 2010/1/18 Markus Rechberger mrechber...@gmail.com mailto:mrechber...@gmail.com On Mon, Jan 18, 2010 at 7:50 PM, fogna fogn...@gmail.com mailto:fogn...@gmail.com wrote: Il 01/18/2010 06:33 PM, Markus Rechberger ha scritto: On Mon, Jan 18, 2010 at 5:36 PM, Devin Heitmueller dheitmuel...@kernellabs.com mailto:dheitmuel...@kernellabs.com wrote: Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com mailto:mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? conexant cx25843 - xceive xc5000 failure (as what I've heard conexant laid off people in that area years ago while xceive (see their driver changelog if you have access to it) tried to fix it with their firmware but didn't succeed), it also happens with windows. Those screenshots are taken from a videoclip it was of course a big problem for business customers (almost all of them happily switched away from it) This is the same retail hardware as everyone else uses out there. XS FM is not being sold anymore. I only know one company in Ireland still ing with it, also in terms of videoquality I'd avoid that combination. Markus Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. 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 mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi Markus, thanks for the info, i didn't know of this hardware problem, i have this usb stick and at the moment all works normally, now i know when it will be time to replace it :) it happens sporadically sometimes 1 time/5 minutes sometimes 1 time/10 minutes. I think in windows it sometimes drops frames it also happens there and can be seen with VLC maybe some codecs also compensate it a little bit. There's no generic rule about this the xc5000 overdrives the videodecoder (it's not empia related issue actually moreover conexant/xceive) Markus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org mailto: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: tm6000: firmware
Am 14.04.2010 19:44, schrieb Mauro Carvalho Chehab: Hi Stefan, Em 14-04-2010 09:26, Stefan Ringel escreveu: Hi Mauro, Can you added these three firmwares? The third is into archive file, because I'm extracted for an user (Bee Hock Goh). Sorry, but for us to put the firmwares at the server and/or add them at linux-firmware git tree, we need to get the distribution rights from the manufacturer, as described on: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission So, we need Xceive's ack, in order to add the firmware files somewhere. That's why currently we're using the procedure described on the comments at the extraction tool: Documentation/video4linux/extract_xc3028.pl Cheers, Mauro OK. In the archive is the modified extract_xc3028 tool for tm6000-xc3028.fw . Is that useful? -- Stefan Ringel stefan.rin...@arcor.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
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 Apr 14 19:00:16 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14561:7c0b887911cf git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 184b7c85f31583632ad00c062a295b622759eef3 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-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 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: tm6000: firmware
Em 14-04-2010 11:41, Stefan Ringel escreveu: Am 14.04.2010 19:44, schrieb Mauro Carvalho Chehab: Hi Stefan, Em 14-04-2010 09:26, Stefan Ringel escreveu: Hi Mauro, Can you added these three firmwares? The third is into archive file, because I'm extracted for an user (Bee Hock Goh). Sorry, but for us to put the firmwares at the server and/or add them at linux-firmware git tree, we need to get the distribution rights from the manufacturer, as described on: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission So, we need Xceive's ack, in order to add the firmware files somewhere. That's why currently we're using the procedure described on the comments at the extraction tool: Documentation/video4linux/extract_xc3028.pl Cheers, Mauro OK. In the archive is the modified extract_xc3028 tool for tm6000-xc3028.fw . Is that useful? Yes, but: 1) Please, send it as a patch, with the proper SOB; 2) From a diff I did here: - my $sourcefile = UDXTTM6000.sys; - my $hash = cb9deb5508a5e150af2880f5b0066d78; - my $outfile = tm6000-xc3028.fw; + my $sourcefile = hcw85bda.sys; + my $hash = 0e44dbf63bb0169d57446aec21881ff2; + my $outfile = xc3028-v27.fw; This version works with another *.sys file. The proper way is to check for the hash, and use the proper logic, based on the provided sys file; 3) Please document where to get the UDXTTTM6000.sys file at the comments; 4) tm6000-xc3028.fw is a really bad name. It made sense only during the development of tuner-xc2028.c, since, on that time, it seemed that tm6000 had a different firmware version. In fact, the first devices appeared with v 1.e firmware. So, a proper name for that version would be xc3028-v1e.fw. We should rename it to be consistent. It is not clear what version is provided with this version. Is it v3.6? On a few cases, we've seen some modified versions of XC3028 firmwares shipped with some specific board. Is it the case? 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
CPiA cam problem
I have an old Ezonics EZCam P10U that I dug up and tried to get working.. but wasn't able to get any video from it. dmesg and relevant VLC messages below. Tested on Debian linux kernel 2.6.32-3-amd64. Am I doing something wrong? Those cpia error messages don't look too happy.. VLC gives the same error when testing on Windows XP. Is my camera dead? dmesg: [76283.900014] usb 8-1: new full speed USB device using uhci_hcd and address 2 [76284.069063] usb 8-1: New USB device found, idVendor=0553, idProduct=0002 [76284.069067] usb 8-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [76284.069070] usb 8-1: Product: USB Camera [76284.069175] usb 8-1: configuration #1 chosen from 1 choice [76284.104794] Linux video capture interface: v2.00 [76284.115534] V4L-Driver for Vision CPiA based cameras v1.2.3 [76284.115536] Since in-kernel colorspace conversion is not allowed, it is disab led by default now. Users should fix the applications in case they don't work wi thout conversion reenabled by setting the 'colorspace_conv' module parameter to 1 [76284.116615] USB driver for Vision CPiA based cameras v1.2.3 [76284.116634] USB CPiA camera found [76284.197067] cpia data error: [8] len=0, status=FFEE [76284.197070] cpia data error: [9] len=0, status=FFEE [76284.197072] cpia_usb_complete: usb_submit_urb ret -2 [76284.197077] cpia data error: [0] len=0, status=FFEE [76284.197079] cpia data error: [1] len=0, status=FFEE [76284.197081] cpia data error: [2] len=0, status=FFEE [76284.197083] cpia data error: [3] len=0, status=FFEE [76284.197085] cpia data error: [4] len=0, status=FFEE [76284.197087] cpia data error: [5] len=0, status=FFEE [76284.197088] cpia data error: [6] len=0, status=FFEE [76284.197090] cpia data error: [7] len=0, status=FFEE [76284.197092] cpia data error: [8] len=0, status=FFEE [76284.197094] cpia data error: [9] len=0, status=FFEE [76284.197096] cpia_usb_complete: usb_submit_urb ret -2 [76284.938150] CPiA Version: 1.30 (2.10) [76284.938153] CPiA PnP-ID: 0553:0002:0100 [76284.938155] VP-Version: 1.0 0141 [76284.938179] usbcore: registered new interface driver cpia vlc complaining: [0x12ad758] v4l2 demux debug: Trying direct kernel v4l2 [0x12ad758] v4l2 demux debug: opening device '/dev/video0' [0x12ad758] v4l2 demux error: cannot get video capabilities (Invalid argument) [0x12ad758] v4l2 demux debug: Trying libv4l2 wrapper [0x12ad758] v4l2 demux debug: opening device '/dev/video0' libv4l2: error getting capabilities: Invalid argument [0x12ad758] v4l2 demux error: cannot get video capabilities (Invalid argument) [0x12ad758] main demux warning: no access_demux module matching v4l2 could be loaded (... it goes on like that a few more times.) Thank you for your help, --Mike Akey -- 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: cx18: missing audio for analog recordings
On 14/04/10 12:32 AM, Mark Lord wrote: .. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. .. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. And a quick grep spin *.[ch] shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. But like I said, I'm only just beginning to look more closely now. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.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: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
Hi, to be honest, there is a little too much delay on those reports. did not even notice a problem with Trent's prior patch. The same is also at vivi. Should I have a file called /etc/modprobe.d/TVanywhereAD that contains the line, options saa7134 card=94 gpio_tracking i2c_debug=1 and then watch the command line output of kaffeine? I've found a GUI that allows tweaking lots of module parameters that I have never heard of. Card=94 in the config file, gpio_tracking and i2c_debug are set to 1 in the GUI. Strange things are appearing in dmesg and syslog. I assume that [snip] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-0: Invalid 7-bit address 0x7a saa7133[0]: i2c xfer: 8e ERROR: NO_DEVICE [snip] is significant. No, not at all for my knowledge. If you want to produce debug output for failing firmware loading from file after a cold boot, yes, you might eventually be able to see that failing tuner initialization brings down i2c. If it is a additional new regression, then mercurial bisect can find the patch in question fairly quick. That sounds like something that I should be able to do, if only I'd read the instructions. It is totally up to you and all others with that hardware. Since already in some multiple broken conditions, never working without flaws previously, I would suggest not to wait any longer, until some sort of hadron collider is available ... First try in all known ways. We likely don't have the budget for anything else that soon ;) Cheers, Hermann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz tl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls awa...@md.metrocast.net wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz tl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. We did have a similar issue with the PCTV 800i. Basically, the GPIO definition was improperly defined for the xc5000 reset callback. As a result, it was strobing the reset on both the xc5000 *and* the s5h1411, which would then cause the s5h1411's hardware state to not match the driver state. After multiple round trips with the hardware engineer at PCTV, I finally concluded that there actually wasn't a way to strobe the reset without screwing up the demodulator, which prompted me to disable the xc5000 reset callback (see cx88-cards:2944). My guess is that the reset GPIO definition for that board is wrong (a problem exposed by this change), or that it's resetting the s5h1411 as well. 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: cx18: missing audio for analog recordings
On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: On 14/04/10 12:32 AM, Mark Lord wrote: .. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. .. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. You can at least logically break it into components: cx18-av-* : the integrated A/V decoder subdevice (very much like a CX25843) cx18-gpio* : logical subdevices for functions controlled by GPIO cx18-alsa* : the ALSA interface presented to userspace cx18-fileops*, cx18-ioctl*, cx18-contorls* : The V4L2 interface cx18-dvb* : The DTV interface cx18-streams* : main streams management, and empty DMA buffer handover cx18-queue*: queue routines used for all queues for all streams cx18-mailbox*, cx18-scb* : driver-firmware API, main body of hard irq handler for incoming DMA, and workhandler for incoming DMA cx18-io* : Insanity to handle CX23418 PCI MMIO quirks cx18-irq* : The hard irq handler cx18-driver* : main driver probe and shutdown cx18-cards*: specifics on each supported card cx18-firmware* : Bridge and MPEG encoder firmware load and init, but not A/V core firmware cx18-i2c* : I2C master setup, bus driving, and device registration cx18-audio*: Top level audio routing functions cx18-video*: Top level video routing functions cx18-vbi* : VBI data extraction But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. The ioctl handling in the driver does it: $ grep serialize_lock * The serialize_lock is a bit overloaded, but it's frequent operational use is ioctl() serialization. The A/V core is almost exclusively manipulated by ioctl()s. The timer I added for fallback is an exception. And a quick grep spin *.[ch] shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Correct. What is involved are the three reset processes in the cx18-av-* files: 1. Stopping and restarting the microcontroller via register 803 2. Soft reset (of what exactly?) via register 0x810 3. Format detection loop restart via register 0x9cc I have no idea if 2 3 above reset hardware and registers, or simply set a flag for the microcontroller firmware to notice, or both. So I've wondered about the exact sequencing of stopping the microcontoller, peforming the other 2 resets, and restarting the microcontroller. Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. There is no need. The hard irq handler only really deals with firmware mailbox ack and firmware mailbox ready notifications. It sucks off the mailbox contents and shoves it over to the cx18-NN-in workhandler via work orders placed on a workqueue. The work handler does grab the spinlocks, but it is from a non-irq context. But like I said, I'm only just beginning to look more closely now. Look at the publicly available CX25843 datasheet: http://dl.ivtvdriver.org/ pages 107-116 and Section 5.7. In figure 3.30 we've got SIF coming in from the analog tuner and the microcontoller is represented by the Auto Std/Mode Detection block. In figure 3-38 the output of the source select block is what then gets fed to the baseband processing chain as digital audio from the tuner. For reference, you may want to also grab FCC docment OET60 (Rev A from 1996?), which technically describes the BTSC audio subcarriers. Then Google for a nice pciture of the MTS/BTSC spectrum. This app note has a good picture in figure 1: http://assets.fluke.com/appnotes/it_products/Anbtsc.pdf although it is missing the PRO channel that is above SAP at 6fh IIRC. I don't know what part of the BTSC spectrum the Conexant microcontroller is keying off of, but I guessing the pilot for sure is part of the decision process. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/04/10 12:46 AM, Andy Walls wrote: On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: .. Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. There is no need. The hard irq handler only really deals with firmware mailbox ack and firmware mailbox ready notifications. It sucks off the mailbox contents and shoves it over to the cx18-NN-in workhandler via work orders placed on a workqueue. The work handler does grab the spinlocks, but it is from a non-irq context. .. Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling. I suppose those might be safe groups, written to _only_ by the IRQ handler, but maybe not. From what I can see, (nearly?) all registers are read/written as full 32-bit units. So when code wants to modify an 8-bit register, this is converted into a read- modify-write of the corresponding 32-bit register. So if two threads, or any thread and the irq handler, want to modify parts of the same 32-bit register, then there's a race. The code _appears_ to mostly not have such a problem, but it would conveniently explain the sporadic failures. :) So, for now, I've added lower level spinlock protection onto all register writes, as well as to routines that themselves do a higher level read-modify-write: eg. the routines to enable/disable specific IRQ sources. This was easy enough to do, and it'll give us confidence that the r-m-w sequences are not the issue. Or perhaps it'll cure some problems. Time will tell. I'll run with that patch on top of yours for the next couple of days, or until I see a fallback log again. None so far, though. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.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
