Hauppauge Nova-T 500 completely nailed after rebooting
Hi, This is something that has been hapening lately (since some months ago). I'm currently using Gentoo 64 bits (kernel 2.6.29, but using LinuxTV HG code for DVB), and I've observed that rebooting the system gets the card completely hanged. This is what happens: · after rebooting, the card initializes itself as normal, and is detected as in 'warm' state (firmware loaded) · then, the following entry appears iun dmesg: ehci_hcd :01:0e.2: force halt; handhake c2042014 4000 - -110 · then, once the mythbackend starts scanning EIT data (or just recording or whatever...) the dmesg is completely filled with this: [ 35.422678] mt2060 I2C write failed (len=2) [ 35.422682] mt2060 I2C write failed (len=6) [ 35.422684] mt2060 I2C read failed [ 35.430001] mt2060 I2C read failed [ 35.440001] mt2060 I2C read failed [ 35.450002] mt2060 I2C read failed [ 35.460007] mt2060 I2C read failed [ 35.47] mt2060 I2C read failed [ 35.480006] mt2060 I2C read failed [ 35.490003] mt2060 I2C read failed [ 35.502033] mt2060 I2C read failed [ 35.51] mt2060 I2C read failed [ 35.954276] mt2060 I2C write failed [ 35.959139] mt2060 I2C write failed (len=2) [ 35.959143] mt2060 I2C write failed (len=6) (at infinitum...) The card is unable to record anything. If I stop the backend, unload dvb_usb_0700 module and reload it then I get the following: [ 397.692455] usbcore: deregistering interface driver dvb_usb_dib0700 [ 397.692937] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully deinitialized and disconnected. [ 408.229251] dib0700: loaded with support for 9 different device-types [ 408.229283] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware [ 408.229286] usb 2-1: firmware: requesting dvb-usb-dib0700-1.20.fw [ 408.244217] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 408.244227] dib0700: firmware download failed at 7 with -108 [ 408.244260] usbcore: registered new interface driver dvb_usb_dib0700 As seen, the card is unable to reinit itself properly any more, so the DVB devices are simply not created. Sometimes, this can be solved by just rebooting a couple of times, but sometimes not. The only real way to fix is to completely power down the machine, unplug AC cord, press power button (which empties capacitors and so...), replug and booting again. This method ensures that the firmware card is unloaded and then properly reloaded, which makes it work fine again. Any ideas? Should I discard LinuxTV drivers and use those in-tree for 2.6.29? Best regards, Eduard -- 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: [REVIEW] v4l2 loopback
Hi Vasily,
Your patch seems to be reversed, not a big deal for review purposes, of
course.
I think you know that if you are working on a hg clone you can simply
issue hg diff to get the right patch, or you could even use 'quilt' to
ease your work.
Just very few comments about syntax and style, since I am not a v4l
dev :)
On Mon, 27 Apr 2009 04:22:58 +0300
Vasily vas...@gmail.com wrote:
Hello Hans,
Here is version with most issues fixed except usage of struct v4l2_device
Can you please tell me more what should I use it for? I do not use any
subdevice feature. It does not remove usage of video_device struct
as I see from vivi driver it just used to be registered and unregistered
and for messages, may be I missed something?
So can you tell please what I should use it for in loopback driver?
Just add it to v4l2_loopback_device structure and registe it?
---
This patch introduces v4l2 loopback module
From: Vasily Levin vas...@gmail.com
This is v4l2 loopback driver which can be used to make available any userspace
video as v4l2 device. Initialy it was written to make videoeffects available
to Skype, but in fact it have many more uses.
Priority: normal
Signed-off-by: Vasily Levin vas...@gmail.com
diff -uprN v4l-dvb.my.p/linux/drivers/media/video/Kconfig
v4l-dvb.orig/linux/drivers/media/video/Kconfig
--- v4l-dvb.my.p/linux/drivers/media/video/Kconfig2009-04-26
21:30:37.0 +0300
+++ v4l-dvb.orig/linux/drivers/media/video/Kconfig2009-04-25
04:41:20.0 +0300
@@ -479,13 +479,6 @@ config VIDEO_VIVI
Say Y here if you want to test video apps or debug V4L devices.
In doubt, say N.
-config VIDEO_V4L2_LOOPBACK
- tristate v4l2 loopback driver
- depends on VIDEO_V4L2 VIDEO_DEV
- help
- Say Y if you want to use v4l2 loopback driver.
- This driver can be compiled as a module, called v4l2loopback.
-
The description here could be improved, don't you think so?
source drivers/media/video/bt8xx/Kconfig
config VIDEO_PMS
diff -uprN v4l-dvb.my.p/linux/drivers/media/video/Makefile
v4l-dvb.orig/linux/drivers/media/video/Makefile
--- v4l-dvb.my.p/linux/drivers/media/video/Makefile 2009-04-26
21:30:37.0 +0300
+++ v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-04-25
04:41:20.0 +0300
@@ -132,7 +132,6 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
-obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
diff -uprN v4l-dvb.my.p/linux/drivers/media/video/v4l2loopback.c
v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
--- v4l-dvb.my.p/linux/drivers/media/video/v4l2loopback.c 2009-04-27
03:07:08.0 +0300
+++ v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
03:00:00.0 +0300
@@ -1,732 +0,0 @@
-/*
- * v4l2loopback.c -- video 4 linux loopback driver
- *
- * Copyright (C) 2005-2009
- * Vasily Levin (vas...@gmail.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- */
Nitpicking here: just one space before the text?
-#include linux/version.h
-#include linux/vmalloc.h
-#include linux/mm.h
-#include linux/time.h
-#include linux/module.h
-#include media/v4l2-ioctl.h
-#include v4l2loopback.h
-
-#define YAVLD_STREAMING
-
-MODULE_DESCRIPTION(V4L2 loopback video device);
-MODULE_VERSION(0.1.1);
-MODULE_AUTHOR(Vasily Levin);
-MODULE_LICENSE(GPL);
-
GPL v2? I am not sure if this is of any importance.
-/* module parameters */
-static int debug = 0;
-module_param(debug, int, 0);
-MODULE_PARM_DESC(debug,if debug output is enabled, values are 0, 1 or 2);
-
To do debug prints, these days, most kernel modules defines DEBUG at
the top of the file (just when needed) and then use pr_debug() or better
dev_dbg() into code.
-static int max_buffers_number = 4;
-module_param(max_buffers_number, int, 0);
-MODULE_PARM_DESC(max_buffers_number,how many buffers should be allocated);
-
-static int max_openers = 10;
-module_param(max_openers, int, 0);
-MODULE_PARM_DESC(max_openers,how many users can open loopback device);
-
-#define dprintk(fmt, args...)\
- if (debug) {\
- printk(KERN_INFO v4l2-loopback: fmt, ##args);\
- }
-
-
-#define dprintkrw(fmt, args...)\
- if (debug 1) {\
- printk(KERN_INFO v4l2-loopback: fmt, ##args);\
- }
-
If you choose to use dev_dbg() these two macros could be dropped, you
will loose debug levels, but it is not a big loss IMHO.
-/* global module data */
-struct v4l2_loopback_device *dev;
-/* forward declarations */
Re: [PATCH 3/8] ARM: convert pcm990 to the new platform-device soc-camera interface
On Mon, 27 Apr 2009, Eric Miao wrote: It looks to me the change to the platform code is to move the I2C board info registration into 'struct soc_camera_link'. Are there any specific reason to do so? I'm assuming the original code works equally well, and lists all the i2c devices in a central place is straight forward. Yes, there are reasons. The first one is, that many i2c camera sensor chips switch on their I2C interface only when the camera interface master clock is running. Therefore you cannot even probe the chip before the host video part has been initialised. So if you load the sensor driver before the host camera driver you cannot probe. The current mainline framework makes the first-stage sensor probe a NOP, in it the sensor driver just registers itself with the soc-camera framework and returns success. And only when the soc-camera finds a match of a sensor and a host driver it requests the host to activate the interface (switch on the master clock) and then the second stage sensor probing is called, which now can actually read chip version registers etc. The second reason is that this is also how v4l2-subdev framework works - there your camera host driver (in our case soc-camera core) uses its internal knowledge about present I2C devices (in our case it uses platform devices with referenced there i2c board info) to register new I2C devices dynamically and load their drivers, at which point we have already switched the master clock on so the sensor driver can just probe the chip normally. 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
[PATCH] [0904_1_1] Siano: core header - update license [Replace 0904_1]
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1240828880 -10800 # Node ID 24e0283cbbc9992ea6bc9775906821e323726f34 # Parent 7311d23c3355629b617013cd51223895a2423770 Modify the file license to match all other Siano's files From: Uri Shkolnik u...@siano-ms.com Modify the file license to match all other Siano's files Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 7311d23c3355 -r 24e0283cbbc9 linux/drivers/media/dvb/siano/smscoreapi.h --- a/linux/drivers/media/dvb/siano/smscoreapi.hSun Mar 15 12:05:57 2009 +0200 +++ b/linux/drivers/media/dvb/siano/smscoreapi.hMon Apr 27 13:41:20 2009 +0300 @@ -1,26 +1,26 @@ -/* - * Driver for the Siano SMS1xxx USB dongle - * - * author: Anatoly Greenblat - * - * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation; - * - * Software distributed under the License is distributed on an AS IS - * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. - * - * See the GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ +/ -#ifndef __smscoreapi_h__ -#define __smscoreapi_h__ +Siano Mobile Silicon, Inc. +MDTV receiver kernel modules. +Copyright (C) 2006-2008, Uri Shkolnik, Anatoly Greenblat + +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 2 of the License, or +(at your option) any later version. + + This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program. If not, see http://www.gnu.org/licenses/. + +/ + +#ifndef __SMS_CORE_API_H__ +#define __SMS_CORE_API_H__ #include linux/version.h #include linux/device.h @@ -598,4 +598,4 @@ int smscore_led_state(struct smscore_dev dprintk(KERN_DEBUG, DBG_ADV, fmt, ##arg) -#endif /* __smscoreapi_h__ */ +#endif /* __SMS_CORE_API_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
[PATCH] [0904_1_2] Siano: core header - update include files
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1240829297 -10800 # Node ID f8f75fb71210dfde89f994a97d8a4fa1e6b7b7bc # Parent 24e0283cbbc9992ea6bc9775906821e323726f34 Re-order the include files list From: Uri Shkolnik u...@siano-ms.com Re-order the include files list, put the DVB-API v3 within its own section, within a define container. Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 24e0283cbbc9 -r f8f75fb71210 linux/drivers/media/dvb/siano/smscoreapi.h --- a/linux/drivers/media/dvb/siano/smscoreapi.hMon Apr 27 13:41:20 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smscoreapi.hMon Apr 27 13:48:17 2009 +0300 @@ -28,15 +28,20 @@ along with this program. If not, see h #include linux/mm.h #include linux/scatterlist.h #include linux/types.h +#include linux/mutex.h +#include linux/wait.h +#include linux/timer.h + #include asm/page.h -#include linux/mutex.h #include compat.h +#define SMS_DVB3_SUBSYS +#ifdef SMS_DVB3_SUBSYS #include dmxdev.h #include dvbdev.h #include dvb_demux.h #include dvb_frontend.h - +#endif #define kmutex_init(_p_) mutex_init(_p_) #define kmutex_lock(_p_) mutex_lock(_p_) -- 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] [0904_4] Siano: core header indentation
[[ Got qmail error on previous mail, re-submit. ]] --- On Mon, 4/27/09, Uri Shkolnik uri...@yahoo.com wrote: Mauro, This patch (original 0904_4) is labeled as RFC but there are no comment at all. Please either accept or comment. 10x, Uri -- 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: [REVIEW] v4l2 loopback
Hi Vasily, Your patch seems to be reversed, not a big deal for review purposes, of course. I think you know that if you are working on a hg clone you can simply issue hg diff to get the right patch, or you could even use 'quilt' to ease your work. Just very few comments about syntax and style, since I am not a v4l dev :) On Mon, 27 Apr 2009 04:22:58 +0300 Vasily vas...@gmail.com wrote: Hello Hans, Here is version with most issues fixed except usage of struct v4l2_device Can you please tell me more what should I use it for? I do not use any subdevice feature. It does not remove usage of video_device struct as I see from vivi driver it just used to be registered and unregistered and for messages, may be I missed something? So can you tell please what I should use it for in loopback driver? Just add it to v4l2_loopback_device structure and registe it? --- This patch introduces v4l2 loopback module From: Vasily Levin vas...@gmail.com This is v4l2 loopback driver which can be used to make available any userspace video as v4l2 device. Initialy it was written to make videoeffects available to Skype, but in fact it have many more uses. Priority: normal Signed-off-by: Vasily Levin vas...@gmail.com diff -uprN v4l-dvb.my.p/linux/drivers/media/video/Kconfig v4l-dvb.orig/linux/drivers/media/video/Kconfig --- v4l-dvb.my.p/linux/drivers/media/video/Kconfig 2009-04-26 21:30:37.0 +0300 +++ v4l-dvb.orig/linux/drivers/media/video/Kconfig 2009-04-25 04:41:20.0 +0300 @@ -479,13 +479,6 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_V4L2_LOOPBACK -tristate v4l2 loopback driver -depends on VIDEO_V4L2 VIDEO_DEV -help - Say Y if you want to use v4l2 loopback driver. - This driver can be compiled as a module, called v4l2loopback. - The description here could be improved, don't you think so? source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff -uprN v4l-dvb.my.p/linux/drivers/media/video/Makefile v4l-dvb.orig/linux/drivers/media/video/Makefile --- v4l-dvb.my.p/linux/drivers/media/video/Makefile 2009-04-26 21:30:37.0 +0300 +++ v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-04-25 04:41:20.0 +0300 @@ -132,7 +132,6 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ obj-$(CONFIG_VIDEO_VIVI) += vivi.o -obj-$(CONFIG_VIDEO_V4L2_LOOPBACK) += v4l2loopback.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o diff -uprN v4l-dvb.my.p/linux/drivers/media/video/v4l2loopback.c v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c --- v4l-dvb.my.p/linux/drivers/media/video/v4l2loopback.c2009-04-27 03:07:08.0 +0300 +++ v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c1970-01-01 03:00:00.0 +0300 @@ -1,732 +0,0 @@ -/* - * v4l2loopback.c -- video 4 linux loopback driver - * - * Copyright (C) 2005-2009 - * Vasily Levin (vas...@gmail.com) - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - */ Nitpicking here: just one space before the text? -#include linux/version.h -#include linux/vmalloc.h -#include linux/mm.h -#include linux/time.h -#include linux/module.h -#include media/v4l2-ioctl.h -#include v4l2loopback.h - -#define YAVLD_STREAMING - -MODULE_DESCRIPTION(V4L2 loopback video device); -MODULE_VERSION(0.1.1); -MODULE_AUTHOR(Vasily Levin); -MODULE_LICENSE(GPL); - GPL v2? I am not sure if this is of any importance. -/* module parameters */ -static int debug = 0; -module_param(debug, int, 0); -MODULE_PARM_DESC(debug,if debug output is enabled, values are 0, 1 or 2); - To do debug prints, these days, most kernel modules defines DEBUG at the top of the file (just when needed) and then use pr_debug() or better dev_dbg() into code. Actually, I prefer a debug module parameter. That way you can enable debugging without recompiling. Given the complexity of video drivers that is often very desirable. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [0904_7_1] Siano: smsdvb - modify license
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1240832608 -10800 # Node ID 39bbe3b24abaaa3e049a855cb51be0b917b0c711 # Parent 4a0b207a424af7f05d8eb417a698a82a61dd086f Siano: smsdvb - Fix licese to match all other Siano's files From: Uri Shkolnik u...@siano-ms.com Siano: smsdvb - Fix license to match all other Siano's files Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r 4a0b207a424a -r 39bbe3b24aba linux/drivers/media/dvb/siano/smsdvb.c --- a/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 20:50:24 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smsdvb.cMon Apr 27 14:43:28 2009 +0300 @@ -1,23 +1,23 @@ -/* - * Driver for the Siano SMS1xxx USB dongle - * - * Author: Uri Shkolni - * - * Copyright (c), 2005-2008 Siano Mobile Silicon, Inc. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation; - * - * Software distributed under the License is distributed on an AS IS - * basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. - * - * See the GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ +/ + +Siano Mobile Silicon, Inc. +MDTV receiver kernel modules. +Copyright (C) 2006-2008, Uri Shkolnik + +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 2 of the License, or +(at your option) any later version. + + This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program. If not, see http://www.gnu.org/licenses/. + +/ #include linux/module.h #include linux/init.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
[PATCH] [0904_7_2] Siano: smsdvb - purge whitespaces
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1240833806 -10800
# Node ID cbd828b0fe102fa023280cfeadbcb20b54a39a47
# Parent 39bbe3b24abaaa3e049a855cb51be0b917b0c711
Siano: smsdvb - whitespace cleanup
From: Uri Shkolnik u...@siano-ms.com
Whitespace cleanup, no implementation changes
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 39bbe3b24aba -r cbd828b0fe10 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cMon Apr 27 14:43:28 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cMon Apr 27 15:03:26 2009 +0300
@@ -33,15 +33,15 @@ struct smsdvb_client_t {
struct smscore_device_t *coredev;
struct smscore_client_t *smsclient;
- struct dvb_adapter adapter;
- struct dvb_demuxdemux;
- struct dmxdev dmxdev;
- struct dvb_frontend frontend;
+ struct dvb_adapter adapter;
+ struct dvb_demux demux;
+ struct dmxdev dmxdev;
+ struct dvb_frontend frontend;
- fe_status_t fe_status;
- int fe_ber, fe_snr, fe_unc, fe_signal_strength;
+ fe_status_t fe_status;
+ int fe_ber, fe_snr, fe_unc, fe_signal_strength;
- struct completion tune_done, stat_done;
+ struct completion tune_done, stat_done;
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
@@ -61,7 +61,7 @@ static int smsdvb_onresponse(void *conte
struct smsdvb_client_t *client = (struct smsdvb_client_t *) context;
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) (((u8 *) cb-p)
+ cb-offset);
- u32 *pMsgData = (u32 *)phdr+1;
+ u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr-msgLength - sizeof(struct SmsMsgHdr_ST);*/
/*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
@@ -177,8 +177,8 @@ static int smsdvb_onresponse(void *conte
if (client-fe_status FE_HAS_LOCK)
sms_board_led_feedback(client-coredev,
- (client-fe_unc == 0) ?
- SMS_LED_HI : SMS_LED_LO);
+ (client-fe_unc == 0) ?
+ SMS_LED_HI : SMS_LED_LO);
else
sms_board_led_feedback(client-coredev, SMS_LED_OFF);
@@ -203,7 +203,7 @@ static void smsdvb_onremove(void *contex
{
kmutex_lock(g_smsdvb_clientslock);
- smsdvb_unregister_client((struct smsdvb_client_t *) context);
+ smsdvb_unregister_client((struct smsdvb_client_t *)context);
kmutex_unlock(g_smsdvb_clientslock);
}
@@ -214,13 +214,12 @@ static int smsdvb_start_feed(struct dvb_
container_of(feed-demux, struct smsdvb_client_t, demux);
struct SmsMsgData_ST PidMsg;
- sms_debug(add pid %d(%x),
- feed-pid, feed-pid);
+ sms_debug(add pid %d(%x), feed-pid, feed-pid);
PidMsg.xMsgHeader.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
PidMsg.xMsgHeader.msgDstId = HIF_TASK;
PidMsg.xMsgHeader.msgFlags = 0;
- PidMsg.xMsgHeader.msgType = MSG_SMS_ADD_PID_FILTER_REQ;
+ PidMsg.xMsgHeader.msgType = MSG_SMS_ADD_PID_FILTER_REQ;
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
@@ -234,31 +233,31 @@ static int smsdvb_stop_feed(struct dvb_d
container_of(feed-demux, struct smsdvb_client_t, demux);
struct SmsMsgData_ST PidMsg;
- sms_debug(remove pid %d(%x),
- feed-pid, feed-pid);
+ sms_debug(remove pid %d(%x), feed-pid, feed-pid);
PidMsg.xMsgHeader.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
PidMsg.xMsgHeader.msgDstId = HIF_TASK;
PidMsg.xMsgHeader.msgFlags = 0;
- PidMsg.xMsgHeader.msgType = MSG_SMS_REMOVE_PID_FILTER_REQ;
+ PidMsg.xMsgHeader.msgType = MSG_SMS_REMOVE_PID_FILTER_REQ;
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed-pid;
- return smsclient_sendrequest(client-smsclient,
-PidMsg, sizeof(PidMsg));
+ return smsclient_sendrequest(client-smsclient, PidMsg,
+ sizeof(PidMsg));
}
static int smsdvb_sendrequest_and_wait(struct smsdvb_client_t *client,
- void *buffer, size_t size,
- struct completion *completion)
+ void *buffer, size_t size,
+ struct completion *completion)
{
- int rc = smsclient_sendrequest(client-smsclient, buffer, size);
+ int rc;
+
+ rc = smsclient_sendrequest(client-smsclient, buffer, size);
if (rc 0)
return rc;
- return wait_for_completion_timeout(completion,
- msecs_to_jiffies(2000)) ?
-
[PATCH] [0904_7_3] Siano: smsdvb - remove redundent complete
# HG changeset patch # User Uri Shkolnik u...@siano-ms.com # Date 1240834193 -10800 # Node ID 5601aa2e8c5e2af2b1f62e03fd4c4e04006c7b87 # Parent cbd828b0fe102fa023280cfeadbcb20b54a39a47 Siano: smsdvb - remove redundant complete instruction From: Uri Shkolnik u...@siano-ms.com Remove redundant complete instruction from smsdvb, in the past this was used by the statistics state machine, but no longer. Priority: normal Signed-off-by: Uri Shkolnik u...@siano-ms.com diff -r cbd828b0fe10 -r 5601aa2e8c5e linux/drivers/media/dvb/siano/smsdvb.c --- a/linux/drivers/media/dvb/siano/smsdvb.cMon Apr 27 15:03:26 2009 +0300 +++ b/linux/drivers/media/dvb/siano/smsdvb.cMon Apr 27 15:09:53 2009 +0300 @@ -550,7 +550,6 @@ static int smsdvb_hotplug(struct smscore client-coredev = coredev; init_completion(client-tune_done); - init_completion(client-stat_done); kmutex_lock(g_smsdvb_clientslock); -- 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] [0904_8] Siano: add messages handling for big-endian target
Mauro, The patch is labeled as rejected Regards, Uri --- On Mon, 4/20/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH] [0904_8] Siano: add messages handling for big-endian target To: Mauro Carvalho Chehab mche...@infradead.org Cc: Uri Shkolnik uri...@yahoo.com, LinuxML linux-media@vger.kernel.org Date: Monday, April 20, 2009, 7:17 PM On Mon, 20 Apr 2009 12:48:39 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Sun, 5 Apr 2009 01:59:50 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: Add code that modify the content of Siano's protocol messages when running with big-endian target. Maybe due to one of the other patches that weren't applied, but this one didn't compile: Sorry, my fault. This is some trash from a previous patch that got rejected. Patch added, thanks. 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] [0904_8] Siano: add messages handling for big-endian target
On Mon, 27 Apr 2009 05:21:29 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: Mauro, The patch is labeled as rejected Ok, I fixed its status at patchwork. Regards, Uri --- On Mon, 4/20/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH] [0904_8] Siano: add messages handling for big-endian target To: Mauro Carvalho Chehab mche...@infradead.org Cc: Uri Shkolnik uri...@yahoo.com, LinuxML linux-media@vger.kernel.org Date: Monday, April 20, 2009, 7:17 PM On Mon, 20 Apr 2009 12:48:39 -0300 Mauro Carvalho Chehab mche...@infradead.org wrote: On Sun, 5 Apr 2009 01:59:50 -0700 (PDT) Uri Shkolnik uri...@yahoo.com wrote: Add code that modify the content of Siano's protocol messages when running with big-endian target. Maybe due to one of the other patches that weren't applied, but this one didn't compile: Sorry, my fault. This is some trash from a previous patch that got rejected. Patch added, thanks. Cheers, Mauro 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] [0904_14] Siano: assemble all components to one kernel module
--- On Tue, 4/21/09, Mauro Carvalho Chehab mche...@infradead.org wrote: From: Mauro Carvalho Chehab mche...@infradead.org Subject: Re: [PATCH] [0904_14] Siano: assemble all components to one kernel module To: Trent Piepho xy...@speakeasy.org Cc: Uri Shkolnik uri...@yahoo.com, linux-media@vger.kernel.org Date: Tuesday, April 21, 2009, 9:10 PM On Tue, 21 Apr 2009 10:54:40 -0700 (PDT) Trent Piepho xy...@speakeasy.org wrote: On Tue, 21 Apr 2009, Uri Shkolnik wrote: --- On Tue, 4/21/09, Trent Piepho xy...@speakeasy.org wrote: From: Trent Piepho xy...@speakeasy.org Subject: Re: [PATCH] [0904_14] Siano: assemble all components to one kernel module To: Uri Shkolnik uri...@yahoo.com Cc: Mauro Carvalho Chehab mche...@infradead.org, LinuxML linux-media@vger.kernel.org Date: Tuesday, April 21, 2009, 6:17 AM On Mon, 20 Apr 2009, Uri Shkolnik wrote: better to have the BUS configurable, e. g. just because you have USB interface, it doesn't mean that you want siano for USB, instead of using SDIO. Since the module is using dynamic registration, I don't find it a problem. When the system has both USB and SDIO buses, both USB and SDIO interface driver will be compiled and linked to the module. When a Siano based device (or multiple Siano devices) will be connected, they will be register internally in the core and activated. Any combination is allow (multiple SDIO, multiple USB and any mix). This is not the way linux drivers normally work. Usually there are multiple modules so that only the ones that need to be loaded are loaded. It sounds like you are designing this to be custom compiled for each system, but that's not usually they way things work. I think I didn't express myself clearly. Lets say that someone build a kernel X. This kernel has (from all buses) only USB. The Siano module will build with USB interface driver at this system. If the system includes SDIO and OMAP SPI/SPP, the module build will discard the USB interface driver, but the SDIO and the OMAP SPI will be built. The patch you've provided just merge everything. If you're proposing a newer model, you should send a patchset with the complete Kbuild refactor. For now, it is better to postpone this patch until we merge non-kbuild changes. Can you name another driver that works this way? It is considered better to build a new module for a different interface. That way one can decide at run time if the interface is needed or not and only load the module if needed. If everything is built into one module then one must decide at compile time what interfaces to support. But it is often the case that kernels are compiled on different systems than run them. This model also sounds different to me from what I've seen so far. 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 Hi, Lets review some other DVB enabled modules 1) PLUTO Kconfig config DVB_PLUTO2 tristate Pluto2 cards depends on DVB_CORE PCI I2C select I2C_ALGOBIT select DVB_TDA1004X help Support for PCI cards based on the Pluto2 FPGA like the Satelco Easywatch Mobile Terrestrial DVB-T Receiver. Since these cards have no MPEG decoder onboard, they transmit only compressed MPEG data over the PCI bus, so you need an external software decoder to watch TV on your computer. Say Y or M if you own such a device and want to use it. As we can see, it depends on PCI and I2C (and DVB_CORE, but that is outside the current discussion), which means, that if the target system lacks either PCI or I2C (and many Linux target do not have those) the entire Pluto module will not be built, even if selected. DM1105 - similar case. TTUSB_BUDGET - config DVB_TTUSB_BUDGET tristate Technotrend/Hauppauge Nova-USB devices depends on DVB_CORE USB I2C PCI select DVB_CX22700 if !DVB_FE_CUSTOMISE select DVB_TDA1004X if !DVB_FE_CUSTOMISE select DVB_VES1820 if !DVB_FE_CUSTOMISE select DVB_TDA8083 if !DVB_FE_CUSTOMISE select DVB_STV0299 if !DVB_FE_CUSTOMISE select DVB_STV0297 if !DVB_FE_CUSTOMISE select DVB_LNBP21 if !DVB_FE_CUSTOMISE help Support for external USB adapters designed by Technotrend and produced by Hauppauge, shipped under the brand name 'Nova-USB'. These devices don't have a MPEG decoder built in, so you need an external software decoder to watch TV. Say Y if you own such a device and want to use it. This module while not be build (even if chosen) on target system that lacks USB stack (additional to PCI
Re: [linux-dvb] Nova HD S2 problem
I am using Mandriva Linux 2009.1 with 2.6.29.1 kernel. My Hauppauge Nova HD S2 (which I understand is known as an HVR4000lite in the DVB API) is not recognised on boot. Using lspci I see the vendor/device code is 0070:4096, whereas the API code (in cx88-cards.c) appears to expect 0070:6096 for this card. Can anyone clue me in? Re-seat the card. - Steve -- 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: [Mjpeg-users] [PATCH] zoran: invalid test on unsigned
On Sun, 26 Apr 2009 17:45:07 +0200 Roel Kluin roel.kl...@gmail.com wrote: fmt-index is unsigned. test doesn't work Signed-off-by: Roel Kluin roel.kl...@gmail.com --- Is there another test required? diff --git a/drivers/media/video/zoran/zoran_driver.c b/drivers/media/video/zoran/zoran_driver.c index 092333b..0db5d0f 100644 --- a/drivers/media/video/zoran/zoran_driver.c +++ b/drivers/media/video/zoran/zoran_driver.c @@ -1871,7 +1871,7 @@ static int zoran_enum_fmt(struct zoran *zr, struct v4l2_fmtdesc *fmt, int flag) if (num == fmt-index) break; } - if (fmt-index 0 /* late, but not too late */ || i == NUM_FORMATS) + if (i == NUM_FORMATS) return -EINVAL; If it's unsigned then don't we need i = NUM_FORMATS ? -- 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
wiki on linixtv.org locked
Hi there, Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage. I would have preferred to undo that damage by simply taking a look at the users contribution page and using the handy-dandy undo function as a mere wiki user. It would have deprived that individual the satifaction of gaining the sysop's attention with his anti-social behavior, but thats probably a policy decision that is not mine to make. Anyway .. Now, after about 24h the wiki is still locked. Any reason for that? cheers -henrik -- 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: wiki on linixtv.org locked
On Mon, Apr 27, 2009 at 06:43:21PM +0200, H. Langos wrote: Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage. I would have preferred to undo that damage by simply taking a look at the users contribution page and using the handy-dandy undo function as a mere wiki user. It would have deprived that individual the satifaction of gaining the sysop's attention with his anti-social behavior, but thats probably a policy decision that is not mine to make. The damage was done by a bot script and it affected as many pages as the edit rate limiter would allow it to do until I noticed it. If you search for GRAWP'S MASSIVE you'll see this is not limited to linuxtv.org. Anyway .. Now, after about 24h the wiki is still locked. Any reason for that? It is locked until I had time to take measures to prevent similar damage from happening again right away. I'm open to suggestions if someone has experience with this. Johannes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GSPCA M5602: Re C99, move storage class to beginning.
Hi,
Thank you for your time reporting this issue.
A similar patch was just posted and merged.
Best regards,
Erik
Robert P. J. Day wrote:
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
diff --git a/drivers/media/video/gspca/m5602/m5602_mt9m111.c
b/drivers/media/video/gspca/m5602/m5602_mt9m111.c
index 7d3f9e3..0167987 100644
--- a/drivers/media/video/gspca/m5602/m5602_mt9m111.c
+++ b/drivers/media/video/gspca/m5602/m5602_mt9m111.c
@@ -31,7 +31,7 @@ static struct v4l2_pix_format mt9m111_modes[] = {
}
};
-const static struct ctrl mt9m111_ctrls[] = {
+static const struct ctrl mt9m111_ctrls[] = {
{
{
.id = V4L2_CID_VFLIP,
diff --git a/drivers/media/video/gspca/m5602/m5602_mt9m111.h
b/drivers/media/video/gspca/m5602/m5602_mt9m111.h
index 00c6db0..6bedf9d 100644
--- a/drivers/media/video/gspca/m5602/m5602_mt9m111.h
+++ b/drivers/media/video/gspca/m5602/m5602_mt9m111.h
@@ -94,7 +94,7 @@ int mt9m111_set_hflip(struct gspca_dev *gspca_dev, __s32
val);
int mt9m111_get_gain(struct gspca_dev *gspca_dev, __s32 *val);
int mt9m111_set_gain(struct gspca_dev *gspca_dev, __s32 val);
-const static struct m5602_sensor mt9m111 = {
+static const struct m5602_sensor mt9m111 = {
.name = MT9M111,
.i2c_slave_id = 0xba,
diff --git a/drivers/media/video/gspca/m5602/m5602_ov9650.c
b/drivers/media/video/gspca/m5602/m5602_ov9650.c
index fc4548f..6c3baca 100644
--- a/drivers/media/video/gspca/m5602/m5602_ov9650.c
+++ b/drivers/media/video/gspca/m5602/m5602_ov9650.c
@@ -68,7 +68,7 @@ static
{}
};
-const static struct ctrl ov9650_ctrls[] = {
+static const struct ctrl ov9650_ctrls[] = {
#define EXPOSURE_IDX 0
{
{
diff --git a/drivers/media/video/gspca/m5602/m5602_ov9650.h
b/drivers/media/video/gspca/m5602/m5602_ov9650.h
index fcc54e4..2ca0e88 100644
--- a/drivers/media/video/gspca/m5602/m5602_ov9650.h
+++ b/drivers/media/video/gspca/m5602/m5602_ov9650.h
@@ -159,7 +159,7 @@ int ov9650_set_auto_white_balance(struct gspca_dev
*gspca_dev, __s32 val);
int ov9650_get_auto_gain(struct gspca_dev *gspca_dev, __s32 *val);
int ov9650_set_auto_gain(struct gspca_dev *gspca_dev, __s32 val);
-const static struct m5602_sensor ov9650 = {
+static const struct m5602_sensor ov9650 = {
.name = OV9650,
.i2c_slave_id = 0x60,
.i2c_regW = 1,
diff --git a/drivers/media/video/gspca/m5602/m5602_po1030.c
b/drivers/media/video/gspca/m5602/m5602_po1030.c
index eaddf48..b06e229 100644
--- a/drivers/media/video/gspca/m5602/m5602_po1030.c
+++ b/drivers/media/video/gspca/m5602/m5602_po1030.c
@@ -31,7 +31,7 @@ static struct v4l2_pix_format po1030_modes[] = {
}
};
-const static struct ctrl po1030_ctrls[] = {
+static const struct ctrl po1030_ctrls[] = {
{
{
.id = V4L2_CID_GAIN,
diff --git a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c
b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c
index 4306d59..bab6cb4 100644
--- a/drivers/media/video/gspca/m5602/m5602_s5k4aa.c
+++ b/drivers/media/video/gspca/m5602/m5602_s5k4aa.c
@@ -64,7 +64,7 @@ static struct v4l2_pix_format s5k4aa_modes[] = {
}
};
-const static struct ctrl s5k4aa_ctrls[] = {
+static const struct ctrl s5k4aa_ctrls[] = {
{
{
.id = V4L2_CID_VFLIP,
diff --git a/drivers/media/video/gspca/m5602/m5602_s5k83a.c
b/drivers/media/video/gspca/m5602/m5602_s5k83a.c
index 42c86aa..689afbc 100644
--- a/drivers/media/video/gspca/m5602/m5602_s5k83a.c
+++ b/drivers/media/video/gspca/m5602/m5602_s5k83a.c
@@ -32,7 +32,7 @@ static struct v4l2_pix_format s5k83a_modes[] = {
}
};
-const static struct ctrl s5k83a_ctrls[] = {
+static const struct ctrl s5k83a_ctrls[] = {
{
{
.id = V4L2_CID_BRIGHTNESS,
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
--
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: 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:Mon Apr 27 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11603:b40d628f830d 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-rc3-armv5: WARNINGS 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-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: ERRORS 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-rc3-i686: ERRORS 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-rc3-m32r: WARNINGS linux-2.6.22.19-mips: WARNINGS linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29.1-mips: WARNINGS linux-2.6.30-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-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: ERRORS 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-rc3-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-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: ERRORS linux-2.6.21.7-i686: ERRORS 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: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build 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
[PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/
Hi Mauro. Let's see if I can make it right this time. Please pull from http://linuxtv.org/hg/~eandren/v4l-dvb/ for a number of 2.6.30+ changes. Best regards, Erik -- 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
HVR1200 stop after RF tracking filter calibration complete
Dear sirs: After I installed the HVR1200, it stop when we tune the frequency. Could anyone tell me what should i do for this situation? Thank you. The message in the log is below kernel: cx23885_dev_checkrevision() Hardware revision unknown 0x0 kernel: cx23885[0]/0: found at :0b:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xfea0 kernel: tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... kernel: firmware: requesting dvb-fe-tda10048-1.0.fw kernel: tda10048_firmware_upload: firmware read 24878 bytes. kernel: tda10048_firmware_upload: firmware uploading kernel: tda10048_firmware_upload: firmware uploaded kernel: tda18271: performing RF tracking filter calibration kernel: tda18271: RF tracking filter calibration complete Audrey -- 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: [Mjpeg-users] [PATCH] zoran: invalid test on unsigned
On Mon, 27 Apr 2009, Alan Cox wrote:
On Sun, 26 Apr 2009 17:45:07 +0200
Roel Kluin roel.kl...@gmail.com wrote:
fmt-index is unsigned. test doesn't work
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Is there another test required?
+++ b/drivers/media/video/zoran/zoran_driver.c
@@ -1871,7 +1871,7 @@ static int zoran_enum_fmt(struct zoran *zr, struct
v4l2_fmtdesc *fmt, int flag)
if (num == fmt-index)
break;
}
- if (fmt-index 0 /* late, but not too late */ || i == NUM_FORMATS)
+ if (i == NUM_FORMATS)
return -EINVAL;
If it's unsigned then don't we need i = NUM_FORMATS ?
That part of the patch is fine. It turns out there is another problem that
already existed in this function. It's clearer with a few more lines of
context.
int num = -1, i;
for (i = 0; i NUM_FORMATS; i++) {
if (zoran_formats[i].flags flag)
num++;
if (num == fmt-index)
break;
}
if (i == NUM_FORMATS)
return -EINVAL;
/* stuff to return format i */
The v4l2 api enumerates formats separately for each buffer type, e.g. there
is one list of formats for video capture and a different list for video
output. The driver just has one list of formats and each format is flagged
with the type(s) it can be used with. So when someone requests the capture
format at index 2 we search the list and return the 3rd capture format we
find. Since we don't know how many capture formats there are (NUM_FORMATS
is the number of formats in the driver's single list, i.e. the union of all
format types) we can't reject an index that is too large until after
searching the whole list.
The problem with this code is if someone requests a format at fmt-index ==
(unsigned)-1. If the first format in the array doesn't have the requested
type then num will still be -1 when it's compared to fmt-index and there
will appear to be a match.
Here's a patch to redo the function that should fix everything:
zoran: fix bug when enumerating format -1
If someone requests a format at fmt-index == (unsigned)-1 and the first
format in the array doesn't have the requested type then num will still be
-1 when it's compared to fmt-index and there will appear to be a match.
Restructure the loop so this can't happen. It's simpler this way too. The
unnecessary check for (unsigned)fmt-index 0 found by Roel Kluin
roel.kl...@gmail.com is removed this way too.
Signed-off-by: Trent Piepho xy...@speakeasy.org
diff -r 63eba6df4b8a -r c247021eb11c
linux/drivers/media/video/zoran/zoran_driver.c
--- a/linux/drivers/media/video/zoran/zoran_driver.cMon Apr 27 12:13:04
2009 -0700
+++ b/linux/drivers/media/video/zoran/zoran_driver.cMon Apr 27 12:25:51
2009 -0700
@@ -1871,22 +1871,20 @@ static int zoran_querycap(struct file *f
static int zoran_enum_fmt(struct zoran *zr, struct v4l2_fmtdesc *fmt, int flag)
{
- int num = -1, i;
-
- for (i = 0; i NUM_FORMATS; i++) {
- if (zoran_formats[i].flags flag)
- num++;
- if (num == fmt-index)
- break;
- }
- if (fmt-index 0 /* late, but not too late */ || i == NUM_FORMATS)
- return -EINVAL;
-
- strncpy(fmt-description, zoran_formats[i].name,
sizeof(fmt-description)-1);
- fmt-pixelformat = zoran_formats[i].fourcc;
- if (zoran_formats[i].flags ZORAN_FORMAT_COMPRESSED)
- fmt-flags |= V4L2_FMT_FLAG_COMPRESSED;
- return 0;
+ unsigned int num, i;
+
+ for (num = i = 0; i NUM_FORMATS; i++) {
+ if (zoran_formats[i].flags flag num++ == fmt-index) {
+ strncpy(fmt-description, zoran_formats[i].name,
+ sizeof(fmt-description) - 1);
+ /* fmt struct pre-zeroed, so adding '\0' not neeed */
+ fmt-pixelformat = zoran_formats[i].fourcc;
+ if (zoran_formats[i].flags ZORAN_FORMAT_COMPRESSED)
+ fmt-flags |= V4L2_FMT_FLAG_COMPRESSED;
+ return 0;
+ }
+ }
+ return -EINVAL;
}
static int zoran_enum_fmt_vid_cap(struct file *file, void *__fh,
--
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: wiki on linixtv.org locked
hi johannes, thank you for your quick reply. On Mon, Apr 27, 2009 at 07:37:41PM +0200, Johannes Stezenbach wrote: On Mon, Apr 27, 2009 at 06:43:21PM +0200, H. Langos wrote: Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage. ... The damage was done by a bot script and it affected as many pages as the edit rate limiter would allow it to do until I noticed it. If you search for GRAWP'S MASSIVE you'll see this is not limited to linuxtv.org. ah, ok .. so it is a stupid kid with scripting knowledge. :-) Anyway .. Now, after about 24h the wiki is still locked. Any reason for that? It is locked until I had time to take measures to prevent similar damage from happening again right away. I'm open to suggestions if someone has experience with this. first of all. please, replace sigh... with a more informative locking message. the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-) if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users. then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books. http://recaptcha.net/plugins/mediawiki/ with that in place you can re-enable new user registration. you can even make logins optional and require captcha solving for anonymous edits. this would probably improve the wiki in general as new users would not jump through yet another loop just in order to help other users... i know, new users can cost more time than they are worth but hope springs eternaly :-) cheers -henrik -- 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] Infos regarding TERRATEC Cinergy HT PCMCIA
Hi Wolfgang, Am Montag, den 27.04.2009, 11:23 +0200 schrieb Wolfgang Friedl: Hello, has anyone tested this card (TERRATEC Cinergy HT PCMCIA) or found useful links I could follow? http://www.terratec.net/de/produkte/Cinergy_HT_PCMCIA_1599.html http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_HT_PCMCIA http://www.linuxtv.org/pipermail/linux-dvb/2006-October/013898.html Googleing around did not bring me further (analogue part should be no problem, with the dvb-t part I am not shure) kind regards, the card was added by Hartmut himself, that is why you don't find much about it on the lists ;) With mercurial installed hg export 4835 will show his patch. Analog and DVB-T is enabled for the cardbus device with PCI subsystem 153b:1172. 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: wiki on linixtv.org locked
On Mon, Apr 27, 2009 at 10:29:25PM +0200, H. Langos wrote: the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-) I will update to 1.14.0. This is the current version, and it is also used by wiki.kernel.org (there is a secret plan to eventually move the wiki there). And all the shiny new anti-spam extensions don't seem to work with 1.11 anymore... if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users. I will do the update first. then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books. http://recaptcha.net/plugins/mediawiki/ Looked at that and noticed they don't provide any statement regarding confidentiality / data protection. Who knows if they aren't creating a huge database of who did what in Wikis and Blogs around the net... Besides that, this wouldn't have stopped the present attack since the bot used does a manual login assisted by a human user. To thwart that I'd have to enable the captcha for every page save... Johannes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How would I record the entire Transport Stream (all PIDs)?
Dale Hopkins wrote: I have successfully opened up the frontend and tuned it to a QAM channel. I have setup a simple PES filter for the PAT on the DEMUX and confirmed that I recieve 188 byte packets with PID=0. Now I want to be able to send all PIDs to the dvr device without having to setup 8192 PES filters. Any suggestions? Filter on PID 0x2000 for all transport packets. - Steve -- 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: wiki on linixtv.org locked
On Tue, Apr 28, 2009 at 12:14:16AM +0200, Johannes Stezenbach wrote: On Mon, Apr 27, 2009 at 10:29:25PM +0200, H. Langos wrote: the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-) I will update to 1.14.0. This is the current version, and it is also used by wiki.kernel.org (there is a secret plan to eventually move the wiki there). And all the shiny new anti-spam extensions don't seem to work with 1.11 anymore... reCAPTCHA seems to work with anything newer than 1.7. if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users. I will do the update first. then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books. http://recaptcha.net/plugins/mediawiki/ Looked at that and noticed they don't provide any statement regarding confidentiality / data protection. Who knows if they aren't creating a huge database of who did what in Wikis and Blogs around the net... I'd rather take a look at the code to see what kind of data is sent off-site. My guess is that there isn't any identification data involved at all. but you are right. they could add that to their faq. OTAH they are a university project and probably didn't approach the whole thing with sufficient paranoia to think about such a question ;-) Besides that, this wouldn't have stopped the present attack since the bot used does a manual login assisted by a human user. To thwart that I'd have to enable the captcha for every page save... hmm, manualy asisted bots are nasty. but maybe there is a way to lower the limit of edits that can be done automatically. maybe a soft limit that would trigger captcha usage way before hitting the hard limit that stoped the bot this time cheers -henrik -- 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] FM1216ME_MK3 some changes
Hi All
Step by step.
This is patch for change only range of FM1216ME_MK3. Slow tunning is not a big
problem.
diff -r b40d628f830d linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Fri Apr 24 01:46:41
2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 28 03:35:42
2009 +1000
@@ -558,8 +558,8 @@
static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
{ 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
- { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
- { 16 * 999.99, 0x8e, 0x04, },
+ { 16 * 441.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 864.00, 0x8e, 0x04, },
};
static struct tuner_params tuner_fm1216me_mk3_params[] = {
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
With my best regards, Dmitry.
Hi Dmitri,
Thank you for you responses.
Just a few more comments...
On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
Hi Andy
Dmitri,
On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
Hi All
1. Change middle band. In the end of the middle band the
sensitivity of receiver not good. If we switch to higher band,
sensitivity more better. Hardware trick.
Several years a go your customers write some messages about bad
quality of TV if frequency of TV is the end of band. It can be low
band or middle. Our hardware engeneer make some tests with hardware
TV generator and our TV tuners.
If we set default frequency range for low and middle band, quality
of TV signal on 159MHz and 442 MHz is bad. When we make our changes
with moving end of bands the quality of TV much better. And our
system programmer for OS Windows use changed bands for drivers.
Customers be happy.
OK. A properly run experiment wins over theory every time. :)
You can test it if in your placement available TV programm on
159MHz or 442MHz. This trick can be usefull for other tuners.
If you look at tveeprom.c, a number of other tuners are using that
tuner definition:
$ grep FM1216ME_MK3 tveeprom.c
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216ME MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216 ME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3, LG S001D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, LG S701D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216LME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3, TCL MFPE05 2},
{ TUNER_PHILIPS_FM1216ME_MK3, TCL MPE05-2},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216ME MK5},
If your change makes things bad for the other tuners, we'll probably
have to create an alternate entry for the other tuners instead of
using the FM1216ME_MK3 defintion. I suspect most of them are clones
of the FM1216ME MK3 however, so it probably won't matter.
3. Set charge pump bit
This will improve the time to initially tune to a frequency, but
will likely add some noise as the PLL continues to maintain lock
on the signal. If there is no way to turn off the CP after the
lock bit is set in the tuner, it's probably better to leave it
off for lower noise and just live with slower tuning.
We discuss with our windows system programmer about it. He sad that
in analog TV mode noise from PLL don't give any problem.
I would be concerned about phase noise affecting the colors or any FM
sound carriers. If the noise isn't noticably affecting colors to the
human eye (do color bars look OK?), or sound to the human ear, then
OK.
But in digital TV mode
noise from PLL decreased BER.
I thought the FM1216ME MK3 was an analog only tuner. I guess I don't
know DVB-T or cable in Europe well enough.
Leaving the CP bit set should be especially noticable ad FM noise
when set to tune to FM radio stations. From the FM1236ME_MK3
datasheet: It is recommended to set CP=0 in the FM mode at all
times. But the VHF low band control byte is also used when
setting FM radio (AFAICT with a quick look at the code.)
Yes. You are right. We can swith CP off in FM mode.
OK. Thank you.
With my best regards, Dmitry.
Regards,
Andy
diff -r b40d628f830d linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Fri Apr 24 01:46:41 2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 28 03:35:42 2009 +1000
@@ -558,8 +558,8 @@
static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
{ 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
- { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
- { 16 * 999.99, 0x8e, 0x04, },
+ { 16 * 441.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 864.00, 0x8e, 0x04, },
};
static struct tuner_params tuner_fm1216me_mk3_params[] = {
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
Re: [PATCH] FM1216ME_MK3 some changes
Hi,
Am Montag, den 27.04.2009, 19:29 +1000 schrieb Dmitri Belimov:
Hi All
Step by step.
This is patch for change only range of FM1216ME_MK3. Slow tunning is not a
big problem.
diff -r b40d628f830d linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Fri Apr 24 01:46:41
2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 28 03:35:42
2009 +1000
@@ -558,8 +558,8 @@
static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
{ 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
- { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
- { 16 * 999.99, 0x8e, 0x04, },
+ { 16 * 441.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 864.00, 0x8e, 0x04, },
};
static struct tuner_params tuner_fm1216me_mk3_params[] = {
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
if it does help anything for having all above 441 MHz in UHF ranges.
Acked-by: Hermann Pitton hermann-pit...@arcor.de
There is simply no known broadcast in that gap on other freq. tables.
Can you please enlighten us who/what broadcasts there?
With my best regards, Dmitry.
Hi Dmitri,
Cheers,
Hermann
Thank you for you responses.
Just a few more comments...
On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
Hi Andy
Dmitri,
On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
Hi All
1. Change middle band. In the end of the middle band the
sensitivity of receiver not good. If we switch to higher band,
sensitivity more better. Hardware trick.
Several years a go your customers write some messages about bad
quality of TV if frequency of TV is the end of band. It can be low
band or middle. Our hardware engeneer make some tests with hardware
TV generator and our TV tuners.
If we set default frequency range for low and middle band, quality
of TV signal on 159MHz and 442 MHz is bad. When we make our changes
with moving end of bands the quality of TV much better. And our
system programmer for OS Windows use changed bands for drivers.
Customers be happy.
OK. A properly run experiment wins over theory every time. :)
You can test it if in your placement available TV programm on
159MHz or 442MHz. This trick can be usefull for other tuners.
If you look at tveeprom.c, a number of other tuners are using that
tuner definition:
$ grep FM1216ME_MK3 tveeprom.c
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216ME MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216 ME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3,LG S001D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, LG S701D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216LME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3,TCL MFPE05 2},
{ TUNER_PHILIPS_FM1216ME_MK3, TCL MPE05-2},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216ME MK5},
If your change makes things bad for the other tuners, we'll probably
have to create an alternate entry for the other tuners instead of
using the FM1216ME_MK3 defintion. I suspect most of them are clones
of the FM1216ME MK3 however, so it probably won't matter.
3. Set charge pump bit
This will improve the time to initially tune to a frequency, but
will likely add some noise as the PLL continues to maintain lock
on the signal. If there is no way to turn off the CP after the
lock bit is set in the tuner, it's probably better to leave it
off for lower noise and just live with slower tuning.
We discuss with our windows system programmer about it. He sad that
in analog TV mode noise from PLL don't give any problem.
I would be concerned about phase noise affecting the colors or any FM
sound carriers. If the noise isn't noticably affecting colors to the
human eye (do color bars look OK?), or sound to the human ear, then
OK.
But in digital TV mode
noise from PLL decreased BER.
I thought the FM1216ME MK3 was an analog only tuner. I guess I don't
know DVB-T or cable in Europe well enough.
Leaving the CP bit set should be especially noticable ad FM noise
when set to tune to FM radio stations. From the FM1236ME_MK3
datasheet: It is recommended to set CP=0 in the FM mode at all
times. But the VHF low band control byte is also used when
setting FM radio (AFAICT with a quick look at the code.)
Yes. You are right. We can swith CP off in FM mode.
OK. Thank you.
With my best regards, Dmitry.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] FM1216ME_MK3 some changes
Am Dienstag, den 28.04.2009, 02:11 +0200 schrieb hermann pitton:
Hi,
Am Montag, den 27.04.2009, 19:29 +1000 schrieb Dmitri Belimov:
Hi All
Step by step.
This is patch for change only range of FM1216ME_MK3. Slow tunning is not a
big problem.
diff -r b40d628f830d linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Fri Apr 24
01:46:41 2009 -0300
+++ b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 28
03:35:42 2009 +1000
@@ -558,8 +558,8 @@
static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
{ 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
- { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
- { 16 * 999.99, 0x8e, 0x04, },
+ { 16 * 441.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 864.00, 0x8e, 0x04, },
};
static struct tuner_params tuner_fm1216me_mk3_params[] = {
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov d.beli...@gmail.com
if it does help anything for having all above 441 MHz in UHF ranges.
for the record: from 441 MHz on ...
Acked-by: Hermann Pitton hermann-pit...@arcor.de
There is simply no known broadcast in that gap on other freq. tables.
Can you please enlighten us who/what broadcasts there?
With my best regards, Dmitry.
Hi Dmitri,
Cheers,
Hermann
Thank you for you responses.
Just a few more comments...
On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
Hi Andy
Dmitri,
On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
Hi All
1. Change middle band. In the end of the middle band the
sensitivity of receiver not good. If we switch to higher band,
sensitivity more better. Hardware trick.
Several years a go your customers write some messages about bad
quality of TV if frequency of TV is the end of band. It can be low
band or middle. Our hardware engeneer make some tests with hardware
TV generator and our TV tuners.
If we set default frequency range for low and middle band, quality
of TV signal on 159MHz and 442 MHz is bad. When we make our changes
with moving end of bands the quality of TV much better. And our
system programmer for OS Windows use changed bands for drivers.
Customers be happy.
OK. A properly run experiment wins over theory every time. :)
You can test it if in your placement available TV programm on
159MHz or 442MHz. This trick can be usefull for other tuners.
If you look at tveeprom.c, a number of other tuners are using that
tuner definition:
$ grep FM1216ME_MK3 tveeprom.c
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216ME MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216 ME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3, LG S001D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, LG S701D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216LME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3, TCL MFPE05 2},
{ TUNER_PHILIPS_FM1216ME_MK3, TCL MPE05-2},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216ME MK5},
If your change makes things bad for the other tuners, we'll probably
have to create an alternate entry for the other tuners instead of
using the FM1216ME_MK3 defintion. I suspect most of them are clones
of the FM1216ME MK3 however, so it probably won't matter.
3. Set charge pump bit
This will improve the time to initially tune to a frequency, but
will likely add some noise as the PLL continues to maintain lock
on the signal. If there is no way to turn off the CP after the
lock bit is set in the tuner, it's probably better to leave it
off for lower noise and just live with slower tuning.
We discuss with our windows system programmer about it. He sad that
in analog TV mode noise from PLL don't give any problem.
I would be concerned about phase noise affecting the colors or any FM
sound carriers. If the noise isn't noticably affecting colors to the
human eye (do color bars look OK?), or sound to the human ear, then
OK.
But in digital TV mode
noise from PLL decreased BER.
I thought the FM1216ME MK3 was an analog only tuner. I guess I don't
know DVB-T or cable in Europe well enough.
Leaving the CP bit set should be especially noticable ad FM noise
when set to tune to FM radio stations. From the FM1236ME_MK3
datasheet: It is recommended to set CP=0 in the FM mode at all
times. But the VHF low band control byte is also used when
setting FM radio (AFAICT with a quick look at the code.)
Yes. You are right. We can swith CP off in FM mode.
OK. Thank you.
With my best regards, Dmitry.
Regards,
Andy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
Re: [PATCH] FM1216ME_MK3 some changes
Hi,
Am Montag, den 27.04.2009, 20:42 +1000 schrieb Dmitri Belimov:
Hi,
Am Montag, den 27.04.2009, 19:29 +1000 schrieb Dmitri Belimov:
Hi All
Step by step.
This is patch for change only range of FM1216ME_MK3. Slow tunning
is not a big problem.
diff -r b40d628f830d linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c Fri
Apr 24 01:46:41 2009 -0300 +++
b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 28
03:35:42 2009 +1000 @@ -558,8 +558,8 @@
static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
{ 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
- { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
- { 16 * 999.99, 0x8e, 0x04, },
+ { 16 * 441.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 864.00, 0x8e, 0x04, },
};
static struct tuner_params tuner_fm1216me_mk3_params[] = {
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
d.beli...@gmail.com
if it does help anything for having all above 441 MHz in UHF ranges.
Acked-by: Hermann Pitton hermann-pit...@arcor.de
There is simply no known broadcast in that gap on other freq. tables.
Can you please enlighten us who/what broadcasts there?
I don't know. This trick for solve problem with low sensitivity the tuners on
end of band.
We get it from measuments.
I believe that, since seen before on real broadcast in the VHF low/high
gap.
But if there is no real broadcast at all, what it is all about for now?
You can find this problem in theory on almost all new tuners, on
every TCL, TENA, YMEC and what the hell else we have melt down to be in
fact only _very few_ new ones.
Get out of the lab, until it is a real problem, but keep in mind.
Cheers,
Hermann
With my best regards, Dmitry.
Hi Dmitri,
Cheers,
Hermann
With my best regards, Dmitry.
Thank you for you responses.
Just a few more comments...
On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
Hi Andy
Dmitri,
On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
Hi All
1. Change middle band. In the end of the middle band the
sensitivity of receiver not good. If we switch to higher
band, sensitivity more better. Hardware trick.
Several years a go your customers write some messages about bad
quality of TV if frequency of TV is the end of band. It can be
low band or middle. Our hardware engeneer make some tests with
hardware TV generator and our TV tuners.
If we set default frequency range for low and middle band,
quality of TV signal on 159MHz and 442 MHz is bad. When we make
our changes with moving end of bands the quality of TV much
better. And our system programmer for OS Windows use changed
bands for drivers. Customers be happy.
OK. A properly run experiment wins over theory every time. :)
You can test it if in your placement available TV programm on
159MHz or 442MHz. This trick can be usefull for other tuners.
If you look at tveeprom.c, a number of other tuners are using that
tuner definition:
$ grep FM1216ME_MK3 tveeprom.c
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216ME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3,Philips FM1216 ME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3,LG S001D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, LG S701D MK3},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FQ1216LME
MK3}, { TUNER_PHILIPS_FM1216ME_MK3,TCL MFPE05 2},
{ TUNER_PHILIPS_FM1216ME_MK3, TCL MPE05-2},
{ TUNER_PHILIPS_FM1216ME_MK3, Philips FM1216ME
MK5},
If your change makes things bad for the other tuners, we'll
probably have to create an alternate entry for the other tuners
instead of using the FM1216ME_MK3 defintion. I suspect most of
them are clones of the FM1216ME MK3 however, so it probably won't
matter.
3. Set charge pump bit
This will improve the time to initially tune to a frequency,
but will likely add some noise as the PLL continues to
maintain lock on the signal. If there is no way to turn off
the CP after the lock bit is set in the tuner, it's probably
better to leave it off for lower noise and just live with
slower tuning.
We discuss with our windows system programmer about it. He sad
that in analog TV mode noise from PLL don't give any problem.
I would be concerned about phase noise affecting the colors or
any FM sound carriers. If the noise isn't noticably affecting
colors to the human eye (do color bars look OK?), or sound to the
human ear, then OK.
But in digital TV mode
noise from PLL decreased BER.
I thought the FM1216ME MK3 was an analog only tuner. I guess I
don't know DVB-T or cable in
Re: [PATCH 3/8] ARM: convert pcm990 to the new platform-device soc-camera interface
On Mon, Apr 27, 2009 at 5:55 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 27 Apr 2009, Eric Miao wrote: It looks to me the change to the platform code is to move the I2C board info registration into 'struct soc_camera_link'. Are there any specific reason to do so? I'm assuming the original code works equally well, and lists all the i2c devices in a central place is straight forward. Yes, there are reasons. The first one is, that many i2c camera sensor chips switch on their I2C interface only when the camera interface master clock is running. Therefore you cannot even probe the chip before the host video part has been initialised. So if you load the sensor driver before the host camera driver you cannot probe. The current mainline framework makes the first-stage sensor probe a NOP, in it the sensor driver just registers itself with the soc-camera framework and returns success. Yes, indeed. The driver has to be carefully written so that no actual I2C access is made during probe, but this makes no sense. One workaround to this is to separate the logic of clock enabling from the camera controller and make a 'struct clk' for it. However, this sounds to be tricky as well. And only when the soc-camera finds a match of a sensor and a host driver it requests the host to activate the interface (switch on the master clock) and then the second stage sensor probing is called, which now can actually read chip version registers etc. The second reason is that this is also how v4l2-subdev framework works - there your camera host driver (in our case soc-camera core) uses its internal knowledge about present I2C devices (in our case it uses platform devices with referenced there i2c board info) to register new I2C devices dynamically and load their drivers, at which point we have already switched the master clock on so the sensor driver can just probe the chip normally. Sounds reasonable. I'm then OK with these 3 patches. -- 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
Panic in HVR-950q caused by changeset 11356
Hello Janne, Ok, so now I need to better understand the nature of changeset 11356. It turns up I spent the entire afternoon debugging a kernel panic on usb disconnect, which ended up being due to this patch: au0828: use usb_interface.dev for v4l2_device_register http://linuxtv.org/hg/v4l-dvb/rev/33810c734a0d The change to pass the interface-dev to v4l2_device_register() effectively overwrote the interface data, so while I thought usb_set_intfdata() was storing the au0828_dev *, in fact it was holding a v4l2_device *. When au0828_usb_disconnect() eventually gets called, the call to usb_get_intfdata() returned the v4l2_device, and presto - instant panic. So, either I can roll back this change, or I can make the call to usb_set_intfdata() *after* the call to v4l2_device_register(). However, I don't know what else that might screw up (I haven't traced out everything in v4l2-device that might expect a v4l2_device * to be stored there). Suggestions? Perhaps if you could provide some additional background as to what prompted this change, it will help me better understand the correct course of action at this point. Devin cc: Robert Krakora and Josh Watzman since they both independently reported what I believe to be the exact same issue (the stack is slightly different because in their case as it crashed in the dvb_unregister portion of the usb_disconnect routine). -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] af9015: support for KWorld MC810
# HG changeset patch
# User Wen-chien Jesse Sung je...@cola.voip.idv.tw
# Date 1240830884 -28800
# Node ID 320b752733803ce674ddcd97645f4873bcae5e27
# Parent 2a6d95947fa1ab72a23c7aabe15dfef52e5b6d8c
af9015: support for KWorld MC810
From: Wen-chien Jesse Sung je...@cola.voip.idv.tw
Add USB ID (1b80:c810) for Kworld MC810.
Priority: normal
Signed-off-by: Wen-chien Jesse Sung je...@cola.voip.idv.tw
diff --git a/linux/drivers/media/dvb/dvb-usb/af9015.c b/linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c
@@ -1267,6 +1267,7 @@ static struct usb_device_id af9015_usb_t
/* 20 */{USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A850)},
{USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A805)},
{USB_DEVICE(USB_VID_KWORLD_2, USB_PID_CONCEPTRONIC_CTVDIGRCU)},
+ {USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_MC810)},
{0},
};
MODULE_DEVICE_TABLE(usb, af9015_usb_table);
@@ -1537,7 +1538,7 @@ static struct dvb_usb_device_properties
.i2c_algo = af9015_i2c_algo,
- .num_device_descs = 2, /* max 9 */
+ .num_device_descs = 3, /* max 9 */
.devices = {
{
.name = AverMedia AVerTV Volar GPS 805 (A805),
@@ -1550,6 +1551,11 @@ static struct dvb_usb_device_properties
.cold_ids = {af9015_usb_table[22], NULL},
.warm_ids = {NULL},
},
+ {
+.name = KWorld Digial MC-810,
+.cold_ids = {af9015_usb_table[23], NULL},
+.warm_ids = {NULL},
+ },
}
},
};
diff --git a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -105,6 +105,7 @@
#define USB_PID_KWORLD_395U0xe396
#define USB_PID_KWORLD_395U_20xe39b
#define USB_PID_KWORLD_395U_30xe395
+#define USB_PID_KWORLD_MC8100xc810
#define USB_PID_KWORLD_PC160_2T0xc160
#define USB_PID_KWORLD_VSTREAM_COLD 0x17de
#define USB_PID_KWORLD_VSTREAM_WARM 0x17df
PATCH recognize Leadtek WinFast DTV Dongle H
Hi all,
please have a look at following patch which adds support for Leadtek WinFast
DTV Dongle H (hybrid - currently only DVB-T reception works, analog is not
supported).
This patch shoud go directly to stable release - no external functionality is
added.
Patch is against latest v4l merculial from linuxtv.org
diff -urN
v4l-dvb-b40d628f830d/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
v4l-dvb-b40d628f830d.edited/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- v4l-dvb-b40d628f830d/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
2009-04-24 06:46:41.0 +0200
+++
v4l-dvb-b40d628f830d.edited/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
2009-04-28 07:19:43.0 +0200
@@ -1498,6 +1498,7 @@
{ USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_MC770) },
{ USB_DEVICE(USB_VID_ELGATO,USB_PID_ELGATO_EYETV_DTT) },
/* 50 */{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_DTT_Dlx) },
+ { USB_DEVICE(USB_VID_LEADTEK,
USB_PID_WINFAST_DTV_DONGLE_STK7700PH) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1821,7 +1822,7 @@
},mche...@redhat.com
},
- .num_device_descs = 7,
+ .num_device_descs = 8,
.devices = {
{ Terratec Cinergy HT USB XE,
{ dib0700_usb_id_table[27], NULL },
@@ -1851,6 +1852,10 @@
{ dib0700_usb_id_table[48], NULL },
{ NULL },
},
+ { LEADTEK WinFast DTV Dongle H,
+ { dib0700_usb_id_table[51], NULL },
+ { NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dib0700_rc_keys,
diff -urN v4l-dvb-b40d628f830d/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
v4l-dvb-b40d628f830d.edited/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- v4l-dvb-b40d628f830d/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
2009-04-24 06:46:41.0 +0200
+++ v4l-dvb-b40d628f830d.edited/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
2009-04-28 07:17:00.0 +0200
@@ -225,6 +225,7 @@
#define USB_PID_WINFAST_DTV_DONGLE_WARM0x6026
#define USB_PID_WINFAST_DTV_DONGLE_STK7700P0x6f00
#define USB_PID_WINFAST_DTV_DONGLE_STK7700P_2 0x6f01
+#define USB_PID_WINFAST_DTV_DONGLE_STK7700PH 0x60f6
#define USB_PID_WINFAST_DTV_DONGLE_GOLD0x6029
#define USB_PID_GENPIX_8PSK_REV_1_COLD 0x0200
#define USB_PID_GENPIX_8PSK_REV_1_WARM 0x0201
After patch you can see this:
usb 3-1: new high speed USB device using ehci_hcd and address 3
usb 3-1: configuration #1 chosen from 1 choice
dib0700: loaded with support for 9 different device-types
dvb-usb: found a 'LEADTEK WinFast DTV Dongle H' in cold state, will try to
load
a firmware
usb 3-1: firmware: requesting dvb-usb-dib0700-1.20.fw
dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
dib0700: firmware started successfully.
dvb-usb: found a 'LEADTEK WinFast DTV Dongle H' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
DVB: registering new adapter (LEADTEK WinFast DTV Dongle H)
DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
xc2028 6-0061: creating new instance
xc2028 6-0061: type set to XCeive xc2028/xc3028 tuner
input: IR-receiver inside an USB DVB receiver as /class/input/input8
dvb-usb: schedule remote query interval to 50 msecs.
dvb-usb: LEADTEK WinFast DTV Dongle H successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_dib0700
i2c-adapter i2c-6: firmware: requesting xc3028-v27.fw
xc2028 6-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028
firmw
are, ver 2.7
xc2028 6-0061: Loading firmware for type=BASE F8MHZ (3), id .
xc2028 6-0061: Loading firmware for type=D2620 DTV8 (208), id
.
xc2028 6-0061: Loading SCODE for type=DTV7 DTV78 DTV8 DIBCOM52 CHINA SCODE
HAS_I
F_5400 (65000380), id .
Best regards
Michal
--
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
