Re: [linux-dvb] DVB-T USB dib0700 device recommendations?
On Mon, Apr 13, 2009 at 4:18 AM, Marco Borm linux-...@retrodesignfan.eu wrote: Hi Henrik, one of the cards in my system is the dib0700 based 'Hauppauge Nova-T 500. Compared with the TerraTec Cinergy 1400 I would say that the receiver sensitivity is worse but the main problem I have is that the card consumes a loot of energy (8-13W), which is much more than the Terratec(5-6W). That's a little bit weird USB itself should provide max 5V 500mA which would be 2.5 Watt; if it requires more then the device has to be self powered. Maybe you can try to use a different USB device (eg. storage) just for testing the consumption. USB is supposed to require alot power (the controller). You might try to unload the ehci/ohci driver too. Markus I calculated this using measure values of the whole system captured with a Conrad/Voltcraft Energy Monitor 3000. Personally I am little bit shocked about that and wondering if this can be true because the dib is a USB-device, but the Voltcraft is one of the better measurement device. Maybe the VIA usb-hub controller on the board is the problem?! Would be interesting of someone has the same or other experiences with this card or other PCI based cards. Hauppauge ignores all my questions, so I can't recomment products of this manufacturer anyway. Greetings, Marco H. Langos wrote: I've been trying to minimize energy consumption [...] But before running out in the street and buying the first dib0700 device I'd like to know if there are any devices that are - especially good [...] or - especially bad [...] ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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] DVB-T USB dib0700 device recommendations?
Hi Markus, it seams that you don't know what the Hauppauge Nova-T 500 is: Its not a USB device itself, its a PCI card with a VIA PCI/USB-Bridge Chip connected to multiple DIBcom USB chips: http://www.bttv-gallery.de/high/bttv-gallery.html I bought the card with the idea in mind that it uses low power USB technology, but that was a mistake. Next time I will buy a real usb device and know it isn't allowed to eat more than 2.5W. Greetings, Marco Markus Rechberger wrote: On Mon, Apr 13, 2009 at 4:18 AM, Marco Borm linux-...@retrodesignfan.eu wrote: Hi Henrik, one of the cards in my system is the dib0700 based 'Hauppauge Nova-T 500. Compared with the TerraTec Cinergy 1400 I would say that the receiver sensitivity is worse but the main problem I have is that the card consumes a loot of energy (8-13W), which is much more than the Terratec(5-6W). That's a little bit weird USB itself should provide max 5V 500mA which would be 2.5 Watt; if it requires more then the device has to be self powered. Maybe you can try to use a different USB device (eg. storage) just for testing the consumption. USB is supposed to require alot power (the controller). You might try to unload the ehci/ohci driver too. Markus I calculated this using measure values of the whole system captured with a Conrad/Voltcraft Energy Monitor 3000. Personally I am little bit shocked about that and wondering if this can be true because the dib is a USB-device, but the Voltcraft is one of the better measurement device. Maybe the VIA usb-hub controller on the board is the problem?! Would be interesting of someone has the same or other experiences with this card or other PCI based cards. Hauppauge ignores all my questions, so I can't recomment products of this manufacturer anyway. Greetings, Marco H. Langos wrote: I've been trying to minimize energy consumption [...] But before running out in the street and buying the first dib0700 device I'd like to know if there are any devices that are - especially good [...] or - especially bad [...] ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: Auto-response for your message to the linux-dvb mailing list
Dear Sirs Thanks for auto-reply response but sorry may be you will re-address, please, Pi-consults offer about possible collaboration in IT-outsourcing software development to relevant department that is responsible for RD or for business development within your entity or to other business partners which are interesting in such outside software development service. I would be grateful to you for these help and assistance. So I look forward to hearing from you. Thanks in advance. BR. Yours truly Viktor Shkel Chief Marketing Officer for www.pi-consult.by Tel: +49 (0) 721 20 12 51 951 ; +375 172 92 41 13 Mobile: +49 (0) 173 8000 751 ; +375 299 137 047 E-mail: sh...@pi-consult.by This ML is deprecated. Please use linux-media@vger.kernel.org instead. For more info about linux-media@vger.kernel.org, please read: http://vger.kernel.org/vger-lists.html#linux-media -- 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: About the radio-si470x driver for I2C interface
I'm not sure about the consequences in case of renaming the radio-si470x module. But it would be consequent to add the appendix -usb and -i2c to the current name. I applied the patch as follows: Okay, your patch is better. Thanks. I will post the i2c part soon after testing. -- 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: About the radio-si470x driver for I2C interface
On 4/13/2009 7:31 PM, Joonyoung Shim wrote: I'm not sure about the consequences in case of renaming the radio-si470x module. But it would be consequent to add the appendix -usb and -i2c to the current name. I applied the patch as follows: Okay, your patch is better. Thanks. I will post the i2c part soon after testing. I have some problem. There is codes for usb in radio-si470x-common.c file. Hrm, if it cannot be removed, maybe it seems to seperate using ifdef. What do you think about this? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compro T750F...Huh? unknown DVB card?, frontend initialization failed
Hi again Hermann,
Your instructions were clear and easy to follow...but still no joy.
This time ending with;
[ 12.291399] saa7133[0]/dvb: Huh? unknown DVB card?
[ 12.291402] saa7133[0]/dvb: frontend initialization failed
I installed mercurial by;
sudo apt-get install mercurial linux-headers-$(uname -r) build-essential
I deleted the existing v4l-dvb folder and got the latest one;
hg clone http://linuxtv.org/hg/v4l-dvb
I changed to the newly created v4l-dvb folder;
cd v4l-dvb
I edited the saa7134-cards.c file in the v4l-dvb folder tree, obscuring
the card from the gpio remotes, as I am not worried about the remote
functionality at this stage;
case SAA7134_BOARD_VIDEOMATE_DVBT_300:
case SAA7134_BOARD_VIDEOMATE_DVBT_200:
case SAA7134_BOARD_VIDEOMATE_DVBT_200A:
/* case SAA7134_BOARD_VIDEOMATE_T750:*/
I compiled the new modules from source;
sudo make
I unloaded the old modules;
sudo make rmmod
I deleted the media folder from
/lib/modules/2.6.28-11-generic/kernel/drivers
I installed the new kernel driver modules;
sudo make install
and rebooted.
The attached text file are dmesg logs with xc3028-v27.fw not
in /lib/firmware and present in /lib/firmware.
Thanks again, for your help.
Andrew
-Original Message-
From: hermann pitton hermann-pit...@arcor.de
To: Andrew Reay cert...@tpg.com.au, John Newbigin j...@it.swin.edu.au
Cc: linux-media@vger.kernel.org
Subject: Re: Compro T750F not working yet...BUG: unable to handle kernel
paging request at fff4
Date: Sat, 11 Apr 2009 13:08:44 +0200
Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Hi Andrew,
the card has in saa7134-dvb.c still a FIXME: does anyone know the
demodulator on it or something like that.
The oops is because the card is set in saa7134-cards.c as gpio remote.
int saa7134_board_init1(struct saa7134_dev *dev)
{
/* Always print gpio, often manufacturers encode tuner type and other
info. */
saa_writel(SAA7134_GPIO_GPMODE0 2, 0);
dev-gpio_value = saa_readl(SAA7134_GPIO_GPSTATUS0 2);
printk(KERN_INFO %s: board init: gpio is %x\n, dev-name,
dev-gpio_value);
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
case SAA7134_BOARD_FLYVIDEO3000_NTSC:
dev-has_remote = SAA7134_REMOTE_GPIO;
board_flyvideo(dev);
break;
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_VIDEOMATE_TV_PVR:
case SAA7134_BOARD_VIDEOMATE_GOLD_PLUS:
case SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUSII:
case SAA7134_BOARD_VIDEOMATE_DVBT_300:
case SAA7134_BOARD_VIDEOMATE_DVBT_200:
case SAA7134_BOARD_VIDEOMATE_DVBT_200A:
case SAA7134_BOARD_VIDEOMATE_T750:
case SAA7134_BOARD_MANLI_MTV001:
But in saa7134-input.c in the function below is nothing for it.
int saa7134_input_init1(struct saa7134_dev *dev)
{
struct card_ir *ir;
struct input_dev *input_dev;
IR_KEYTAB_TYPE *ir_codes = NULL;
u32 mask_keycode = 0;
u32 mask_keydown = 0;
u32 mask_keyup = 0;
int polling = 0;
int rc5_gpio = 0;
int nec_gpio = 0;
int ir_type = IR_TYPE_OTHER;
int err;
if (dev-has_remote != SAA7134_REMOTE_GPIO)
return -ENODEV;
if (disable_ir)
return -ENODEV;
/* detect configure */
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
ir_codes = ir_codes_flyvideo;
mask_keycode = 0xEC0;
mask_keydown = 0x004;
break;
.
.
.
case SAA7134_BOARD_VIDEOMATE_TV_PVR:
case SAA7134_BOARD_VIDEOMATE_GOLD_PLUS:
case SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUSII:
ir_codes = ir_codes_videomate_tv_pvr;
mask_keycode = 0x3F;
mask_keyup = 0x40;
polling = 50; // ms
break;
case SAA7134_BOARD_PROTEUS_2309:
ir_codes = ir_codes_proteus_2309;
mask_keycode = 0x7F;
mask_keyup = 0x80;
polling = 50; // ms
break;
case SAA7134_BOARD_VIDEOMATE_DVBT_300:
case SAA7134_BOARD_VIDEOMATE_DVBT_200:
ir_codes = ir_codes_videomate_tv_pvr;
mask_keycode = 0x003F00;
mask_keyup = 0x04;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
case SAA7134_BOARD_FLYDVBT_LR301:
.
.
.
break;
case SAA7134_BOARD_KWORLD_PLUS_TV_ANALOG:
ir_codes = ir_codes_kworld_plus_tv_analog;
mask_keycode = 0x7f;
polling = 40; /* ms */
break;
Re: About the radio-si470x driver for I2C interface
On Monday 13 April 2009 03:14:13 Alexey Klimov wrote: Hello, Tobias On Mon, Apr 13, 2009 at 12:56 AM, Tobias Lorenz tobias.lor...@gmx.net wrote: Hi Joonyoung, Hi Alexey, I've split the driver into a couple of segments: - radio-si470x-common.c is for common functions - radio-si470x-usb.c are the usb support functions - radio-si470x-i2c.c is an untested prototyped file for your i2c support functions - radio-si470x.h is a header file with everything required by the c-files I hope this is a basis we can start on with i2c support. What do you think? The URL is: http://linuxtv.org/hg/~tlorenz/v4l-dvb Bye, Toby Great! It's always interesting to see big changes. I understand i2c interface not so good and have only general questions. Many (most?) drivers in v4l tree were converted to use new v4l2- framework. For example, dsbr100 was converted to v4l2_device http://linuxtv.org/hg/v4l-dvb/rev/77f37ad5dd0c and em28xx was converted to v4l2_subdev http://linuxtv.org/hg/v4l-dvb/rev/00525b115901 As i remember, Hans Verkuil said that all v4l drivers should be converted to new framework. Is it time to switch to this new interface ? Probably, there are a lot of code examples in current tree that can help.. Any new v4l2 i2c driver must use v4l2_subdev in order to be reusable by v4l2 drivers. All 'legacy' i2c drivers are now converted and only soc-camera and v4l2-int-device.h based drivers remain unconverted, although I expect that those will also be moved to v4l2_subdev in 2.6.31. What complicates matters here is that the si470x is a radio tuner, and as such should be implemented as a tuner device (common/tuners) which have their own framework. But if memory serves the si470x can also do RDS for which there is no support in the tuner framework. I'm leaning towards implementing this i2c driver as a normal v4l2_subdev driver, rather than making it part of the tuner driver/framework. Actually, I suspect that the tuner driver/framework can be substantially simplified with this new framework: much of the complexity there is related to the autoprobing crap, and that no longer applies. This is an interesting future research topic :-) And second question. About lock/unlock_kernel in open functions. Please, take a look at http://www.spinics.net/lists/linux-media/msg04057.html Well, is it time to do something with this? Yes, please remove/replace these calls. Regards, Hans Well, my questions about improving functionality, not about mistakes or bugs :) -- 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
Re: [REVIEW] v4l2 loopback
On Thursday 26 March 2009 19:49:10 Vasily wrote:
Hello, please review the new version of v4l2 loopback driver.
I fixed up comments to the previous submission, waiting for the new ones
:-), reposting for patchwork tool
---
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.
Hi Vasily,
It's still on my todo list, but I have had very little time. If you still
haven't seen a review in two weeks time, then please send me a reminder.
Sorry about this, normally I review things like this much sooner but it has
been very hectic lately.
Regards,
Hans
Priority: normal
Signed-off-by: Vasily Levin vas...@gmail.com
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Kconfig
v4l-dvb.my/linux/drivers/media/video/Kconfig ---
v4l-dvb.orig/linux/drivers/media/video/Kconfig2009-03-21
07:08:06.0 +0200 +++
v4l-dvb.my/linux/drivers/media/video/Kconfig 2009-03-25
23:36:13.0 +0200 @@ -465,6 +465,13 @@ 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.
+
source drivers/media/video/bt8xx/Kconfig
config VIDEO_SAA6588
diff -uprN v4l-dvb.orig/linux/drivers/media/video/Makefile
v4l-dvb.my/linux/drivers/media/video/Makefile ---
v4l-dvb.orig/linux/drivers/media/video/Makefile 2009-03-21
07:08:06.0 +0200 +++
v4l-dvb.my/linux/drivers/media/video/Makefile 2009-03-24
12:54:59.0 +0200 @@ -132,6 +132,7 @@ 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_MX3) += mx3_camera.o
diff -uprN v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c
v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c ---
v4l-dvb.orig/linux/drivers/media/video/v4l2loopback.c 1970-01-01
03:00:00.0 +0300 +++
v4l-dvb.my/linux/drivers/media/video/v4l2loopback.c 2009-03-25
23:01:35.0 +0200 @@ -0,0 +1,725 @@
+/*
+ * 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.
+ *
+ */
+#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 DEBUG
+#define DEBUG_RW */
+#define YAVLD_STREAMING
+
+#ifdef DEBUG
+#define dprintk(fmt, args...)\
+ do {\
+ printk(KERN_INFO v4l2-loopback: fmt, ##args);\
+ } while (0)
+#else
+#define dprintk(fmt, args...)
+#endif
+
+#ifdef DEBUG_RW
+#define dprintkrw(fmt, args...)\
+ do {\
+ printk(KERN_INFO v4l2-loopback: fmt, ##args);\
+ } while (0)
+#else
+#define dprintkrw(fmt, args...)
+#endif
+
+/* global module data */
+struct v4l2_loopback_device *dev;
+/* forward declarations */
+static void init_buffers(int buffer_size);
+static const struct v4l2_file_operations v4l2_loopback_fops;
+static const struct v4l2_ioctl_ops v4l2_loopback_ioctl_ops;
+/
+ my queue helpers ***
+/
+/* next functions sets buffer flags and adjusts counters accordingly */
+static void set_done(struct v4l2_buffer *buffer)
+{
+ buffer-flags |= V4L2_BUF_FLAG_DONE;
+ buffer-flags = ~V4L2_BUF_FLAG_QUEUED;
+}
+
+static void set_queued(struct v4l2_buffer *buffer)
+{
+ buffer-flags |= V4L2_BUF_FLAG_QUEUED;
+ buffer-flags = ~V4L2_BUF_FLAG_DONE;
+}
+
+static void unset_all(struct v4l2_buffer *buffer)
+{
+ buffer-flags = ~V4L2_BUF_FLAG_QUEUED;
+ buffer-flags = ~V4L2_BUF_FLAG_DONE;
+}
+/
+ V4L2 ioctl caps and params calls ***
+/
+/***
***/ +/* returns device capabilities, called on VIDIOC_QUERYCAP
ioctl*/ +static int
Re: [PATCH v2 0/4] ARM: DaVinci: DM646x Video: DM646x display driver
On Wednesday 08 April 2009 13:17:56 Chaithrika U S wrote: Display driver for TI DM646x EVM Signed-off-by: Manjunath Hadli m...@ti.com Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Chaithrika U S chaithr...@ti.com These patches add the display driver support for TI DM646x EVM. This patch set has been tested for basic display functionality for Composite and Component outputs. In this version of the patches, the review comments got for the earlier version have been incorporated. The standard information(timings) has been moved to the display driver. The display driver has been modified accordingly. Also simplified the code by removing the redundant vpif_stdinfo data structure. Patch 1: Display device platform and board setup Patch 2: VPIF driver Patch 3: DM646x display driver Patch 4: Makefile and config files modifications for Display Some of the features like the HBI/VBI support are not yet implemented. Also there are some known issues in the code implementation like fine tuning to be done to TRY_FMT ioctl.The USERPTR usage has not been tested extensively. Time permitting I'll review this during the weekend. During a very superficial scan I saw a few things that could be improved, but I think it only needs one more cycle before it can be merged. It looks much, much better now! Regards, Hans -Chaithrika -- 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 -- 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
Re: [linux-dvb] DVB-T USB dib0700 device recommendations?
On Mon, Apr 13, 2009 at 08:54:09AM +0200, Markus Rechberger wrote: On Mon, Apr 13, 2009 at 4:18 AM, Marco Borm linux-...@retrodesignfan.eu wrote: H. Langos wrote: I've been trying to minimize energy consumption [...] But before running out in the street and buying the first dib0700 device I'd like to know if there are any devices that are - especially good [...] or - especially bad [...] Hi Henrik, one of the cards in my system is the dib0700 based 'Hauppauge Nova-T 500. Compared with the TerraTec Cinergy 1400 I would say that the receiver sensitivity is worse but the main problem I have is that the card consumes a loot of energy (8-13W), which is much more than the Terratec(5-6W). That's a little bit weird USB itself should provide max 5V 500mA which would be 2.5 Watt; if it requires more then the device has to be self powered. I agree, it is wierd, there is a lot of hardware out there that strains the usb power supply way beyond the secified 500mA but that alone can't explain the 8-13 Watt. My guess is, that the rest of your system uses more energy because it has to deal with a USB device instead of a PCI device. There is different hardware involved that otherwise might not be powered at all and there's the whole USB protocol stack that is involved and possibly a usb hid device (the remote) that has to be polled x times per second. Don't let a name like interrupt transfer mode fool you. USB transfers are always initiated by the host, so it has to poll input devices a lot. How exactly did you measure the power usage? Did you run the same software to test it? (zap uses way less energy than vdr) The same channel? (Different bitrates even within the same channel can have some effects) I tried to minimize the effects of the software by making sure that an idle system with the hardware installed has the same cpu load and wakups-per-second as the system without that hardware. But it admit i didn't measure power usage directly. Since I am only dealing with usb devices, I could run the usb pin 1 through an amp meter... Maybe you can try to use a different USB device (eg. storage) just for testing the consumption. USB is supposed to require alot power (the controller). You might try to unload the ehci/ohci driver too. Yeap, thats the way to go. And try running powertop to see if your cpu does any extra work even when it should be idle. I calculated this using measure values of the whole system captured with a Conrad/Voltcraft Energy Monitor 3000. Personally I am little bit shocked about that and wondering if this can be true because the dib is a USB-device, but the Voltcraft is one of the better measurement device. Does it deal well with switched-mode power supplies? Those things tend to confuse power measuring devices unless they have a good active PCF. Maybe the VIA usb-hub controller on the board is the problem?! Could be part of the problem. Would be interesting of someone has the same or other experiences with this card or other PCI based cards. Hauppauge ignores all my questions, so I can't recomment products of this manufacturer anyway. Good to know. Thank you! 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: tuner-core i2c address range check: time to remove them?
On Sunday 29 March 2009 22:53:01 Hans Verkuil wrote: Hi all, The tuner-core.c source contains this warning since 2.6.24: tuner_warn(Support for tuners in i2c address range 0x64 thru 0x6f\n); tuner_warn(will soon be dropped. This message indicates that your\n); tuner_warn(hardware has a %s tuner at i2c address 0x%02x.\n, t-name, t-i2c-addr); tuner_warn(To ensure continued support for your device, please\n); tuner_warn(send a copy of this message, along with full dmesg\n); tuner_warn(output to v4l-dvb-maintai...@linuxtv.org\n); tuner_warn(Please use subject line: \obsolete tuner i2c address.\\n); tuner_warn(driver: %s, addr: 0x%02x, type: %d (%s)\n, t-i2c-adapter-name, t-i2c-addr, t-type, t-name); Isn't it time to remove these i2c addresses? I don't believe we ever had a real tuner at such an address. With the ongoing v4l2_subdev conversion I need to do a bit of cleanup in tuner-core.c as well, so it would be a good time for me to combine it (and it gets rid of an ugly cx88 hack in tuner-core.c as well). Regards, Hans Mike, please let me know if I can remove this! Thanks, 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
Re: Dark picture on Genius E-Messenger 112 webcam with yesterday's v4l-dvb code.
On Sunday 12 April 2009 21:08:31 you wrote: You may ask to Hans de Goede who is the maintainer of the pac207 driver. Cheers. After some thinking, I decided to contact maintainer of pac207, because problem most likely belong to that module. Thanks for the help. -- Best regards, Victor -- 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
Kworld ATSC 120 remote sensor - bad news
I finally got a response from Kworld regarding that mystery IC that listens to the remote control, and it's all bad news. :-( The respondent (a member of the Kworld engineering department, it appears) first tried to use my OS as an excuse, but I pressed anyway. He tells me that both Kworld and the outsourced manufacturer who actually made the card, have lost all of the technical data regarding it. In short, both firms claim to know even less than we do. I have now turned my attention to Geniatech, since the Thriller X8000A is an exact clone of (or was cloned by) the ATSC 120. I have thus far received no response, but I'll keep the list informed. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~vanessa/ Vanessa Ezekowitz vanessaezekow...@gmail.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
[PATCH] pxa_camera: Documentation of the FSM
After DMA redesign, the pxa_camera dynamic behaviour should be documented so that future contributors understand how it works, and improve it. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr --- Documentation/video4linux/pxa_camera.txt | 49 ++ 1 files changed, 49 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt index b1137f9..b595e94 100644 --- a/Documentation/video4linux/pxa_camera.txt +++ b/Documentation/video4linux/pxa_camera.txt @@ -26,6 +26,55 @@ Global video workflow Once the last buffer is filled in, the QCI interface stops. + c) Capture global finite state machine schema + + ++ +---+ ++ + | DQ | | Q | | DQ | + |v | v |v ++---+ ++ +| STOP| | Wait for capture start | ++---+ Q ++ ++- | QCI: stop | -- | QCI: run | + +| | DMA: stop | | DMA: stop | | +| +---+ +- ++ | +|/| | +| / +---+ ++ | | +|capture list empty/ | Q | | DQ | | QCI Irq EOF | +| / | v |v v | +| ++ +--+ | +| | DMA hotlink missed | |Capture running | | +| ++ +--+ | +| | QCI: run | +- | QCI: run | -+ | +| | DMA: stop |/| DMA: run | | | +| ++ / +--+ | Other | +| ^ /DMA still| | channels | +| | capture list / running | DMA Irq End | not | +| | not empty / | | finished | +| | /v | yet | +| +--+ +--+ | | +| | Videobuf released | | Channel completed | | | +| +--+ +--+ | | +| | QCI: run | | QCI: run | --+ | +| | DMA: run | | DMA: run | | +| +--+ +--+ | +| ^ / | | +| | no overrun /| overrun | +| |/ v | +| ++ / +--+ | +| | Frame completed |/| Frame overran| | +| ++ -+ +--+ restart frame | ++-- | QCI: run | | QCI: stop| --+ +| DMA: run | | DMA: stop| +++ +--+ + +Legend: - each box is a FSM state +- each arrow is the condition to transition to another state +- an arrow with a comment is a mandatory transition (no condition) +- arrow Q means : a buffer was enqueued +- arrow DQ means : a buffer was dequeued +- QCI: stop means the QCI interface is not enabled +- DMA: stop means all 3 DMA channels are stopped +- DMA: run means at least 1 DMA channel is still running DMA usage - -- 1.6.2.1 -- 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: Testing latest mx3_camera.c
On Mon, 13 Apr 2009, Agustin wrote: Which patchset should one use today to have latest and most stable mx3_camera driver in 2.6.29? Until now, I have been using mx3_camera (/soc_camera) to interface a custom 7.5MPix 12bpp camera on a PCM037 based system running linux 2.6.28-next plus your November 2009 soc_camera patchset. I have also added support for 16 bit data in IDMAC driver though I have tested just 12. I currently use OSELAS i.MX31 BSP Release 10, that is 2.6.29 plus a patch stack prepared by Sascha Hauer / Pengutronix. On top of that I am applying the v4l-20090408 series from http://gross-embedded.homelinux.org/~lyakh/v4l-20090408/, with little merging effort. Please, use http://marc.info/?l=linux-arm-kernelm=123866462620240w=2 also notice, which patches it needs. As a basis you can take linux-next or a suitable branch from git://git.pengutronix.de/git/imx/linux-2.6.git Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] pxa_camera: Documentation of the FSM
On Mon, 13 Apr 2009, Robert Jarzmik wrote: After DMA redesign, the pxa_camera dynamic behaviour should be documented so that future contributors understand how it works, and improve it. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr --- Documentation/video4linux/pxa_camera.txt | 49 ++ 1 files changed, 49 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt index b1137f9..b595e94 100644 --- a/Documentation/video4linux/pxa_camera.txt +++ b/Documentation/video4linux/pxa_camera.txt @@ -26,6 +26,55 @@ Global video workflow Once the last buffer is filled in, the QCI interface stops. + c) Capture global finite state machine schema + + ++ +---+ ++ + | DQ | | Q | | DQ | + |v | v |v ++---+ ++ +| STOP| | Wait for capture start | ++---+ Q ++ ++- | QCI: stop | -- | QCI: run | + +| | DMA: stop | | DMA: stop | | +| +---+ +- ++ | +|/| | +| / +---+ ++ | | +|capture list empty/ | Q | | DQ | | QCI Irq EOF | +| / | v |v v | +| ++ +--+ | +| | DMA hotlink missed | |Capture running | | +| ++ +--+ | +| | QCI: run | +- | QCI: run | -+ | +| | DMA: stop |/| DMA: run | | | +| ++ / +--+ | Other | +| ^ /DMA still| | channels | +| | capture list / running | DMA Irq End | not | +| | not empty / | | finished | +| | /v | yet | +| +--+ +--+ | | +| | Videobuf released | | Channel completed | | | +| +--+ +--+ | | +| | QCI: run | | QCI: run | --+ | +| | DMA: run | | DMA: run | | +| +--+ +--+ | +| ^ / | | +| | no overrun /| overrun | +| |/ v | +| ++ / +--+ | +| | Frame completed |/| Frame overran| | +| ++ -+ +--+ restart frame | ++-- | QCI: run | | QCI: stop| --+ +| DMA: run | | DMA: stop| +++ +--+ + +Legend: - each box is a FSM state +- each arrow is the condition to transition to another state +- an arrow with a comment is a mandatory transition (no condition) +- arrow Q means : a buffer was enqueued +- arrow DQ means : a buffer was dequeued +- QCI: stop means the QCI interface is not enabled +- DMA: stop means all 3 DMA channels are stopped +- DMA: run means at least 1 DMA channel is still running DMA usage - Cool, nice:-) One question though: shouldn't the capture list empty transition start from Videobuf released state? Or maybe you want to reorginise the Videobuf released and Frame completed states a bit to separate cases - capture list empty - capture list not empty - DMA still running - hot-linking success - DMA stopped - restart Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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] pxa_camera: Documentation of the FSM
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Cool, nice:-) One question though: shouldn't the capture list empty transition start from Videobuf released state? Absolutely. Nice catch. I just cross-checked my hand-made schema, and you're right. Or maybe you want to reorginise the Videobuf released and Frame completed states a bit to separate cases - capture list empty - capture list not empty - DMA still running - hot-linking success - DMA stopped - restart Well, granted that the transition capture list empty was badly put, this is not needed anymore, is it ? Cheers. -- Robert From 8f33b15891c8fe8ee317a8d0d7293d05fda3c6e6 Mon Sep 17 00:00:00 2001 From: Robert Jarzmik robert.jarz...@free.fr Date: Mon, 13 Apr 2009 18:52:56 +0200 Subject: [PATCH] pxa_camera: Documentation of the FSM After DMA redesign, the pxa_camera dynamic behaviour should be documented so that future contributors understand how it works, and improve it. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr --- Documentation/video4linux/pxa_camera.txt | 49 ++ 1 files changed, 49 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt index b1137f9..4f6d0ca 100644 --- a/Documentation/video4linux/pxa_camera.txt +++ b/Documentation/video4linux/pxa_camera.txt @@ -26,6 +26,55 @@ Global video workflow Once the last buffer is filled in, the QCI interface stops. + c) Capture global finite state machine schema + + ++ +---+ ++ + | DQ | | Q | | DQ | + |v | v |v ++---+ ++ +| STOP| | Wait for capture start | ++---+ Q ++ ++- | QCI: stop | -- | QCI: run | + +| | DMA: stop | | DMA: stop | | +| +---+ +- ++ | +|/| | +| / +---+ ++ | | +|capture list empty/ | Q | | DQ | | QCI Irq EOF | +| / | v |v v | +| ++ +--+ | +| | DMA hotlink missed | |Capture running | | +| ++ +--+ | +| | QCI: run | +- | QCI: run | -+ | +| | DMA: stop |/| DMA: run | | | +| ++ / +--+ | Other | +| ^ /DMA still| | channels | +| | capture list / running | DMA Irq End | not | +| | not empty / | | finished | +| | /v | yet | +| +--+ +--+ | | +| | Videobuf released | | Channel completed | | | +| +--+ +--+ | | ++-- | QCI: run | | QCI: run | --+ | +| DMA: run | | DMA: run | | ++--+ +--+ | + ^ / | | + | no overrun /| overrun | + |/ v | +++ / +--+ | +| Frame completed |/| Frame overran| | +++ -+ +--+ restart frame | +| QCI: run | | QCI: stop| --+ +| DMA: run | | DMA: stop| +++ +--+ + +Legend: - each box is a FSM state +- each arrow is the condition to transition to another state +- an arrow with a comment is a mandatory transition (no condition) +- arrow Q means : a buffer was enqueued +- arrow DQ means : a buffer was dequeued +- QCI: stop means the QCI interface is not enabled +- DMA: stop means all 3 DMA channels are stopped +- DMA: run means at least 1 DMA channel is still running DMA usage - -- 1.6.2.1 -- To
Re: Compro T750F...Huh? unknown DVB card?, frontend initialization failed
Hi Andrew, just a short reply for now. Am Montag, den 13.04.2009, 20:46 +1000 schrieb Andrew Reay: Hi again Hermann, Your instructions were clear and easy to follow...but still no joy. This time ending with; [ 12.291399] saa7133[0]/dvb: Huh? unknown DVB card? [ 12.291402] saa7133[0]/dvb: frontend initialization failed I installed mercurial by; sudo apt-get install mercurial linux-headers-$(uname -r) build-essential I deleted the existing v4l-dvb folder and got the latest one; hg clone http://linuxtv.org/hg/v4l-dvb I changed to the newly created v4l-dvb folder; cd v4l-dvb I edited the saa7134-cards.c file in the v4l-dvb folder tree, obscuring the card from the gpio remotes, as I am not worried about the remote functionality at this stage; case SAA7134_BOARD_VIDEOMATE_DVBT_300: case SAA7134_BOARD_VIDEOMATE_DVBT_200: case SAA7134_BOARD_VIDEOMATE_DVBT_200A: /* case SAA7134_BOARD_VIDEOMATE_T750:*/ I compiled the new modules from source; sudo make I unloaded the old modules; sudo make rmmod I deleted the media folder from /lib/modules/2.6.28-11-generic/kernel/drivers I installed the new kernel driver modules; sudo make install and rebooted. The attached text file are dmesg logs with xc3028-v27.fw not in /lib/firmware and present in /lib/firmware. Thanks again, for your help. Andrew -Original Message- From: hermann pitton hermann-pit...@arcor.de To: Andrew Reay cert...@tpg.com.au, John Newbigin j...@it.swin.edu.au Cc: linux-media@vger.kernel.org Subject: Re: Compro T750F not working yet...BUG: unable to handle kernel paging request at fff4 Date: Sat, 11 Apr 2009 13:08:44 +0200 Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Hi Andrew, the card has in saa7134-dvb.c still a FIXME: does anyone know the demodulator on it or something like that. The oops is because the card is set in saa7134-cards.c as gpio remote. [snip] OK, that one is gone. einfaches Textdokument-Anlage (dmesg_dumps.txt) [ 11.458398] Linux video capture interface: v2.00 [ 11.548414] saa7130/34: v4l2 driver version 0.2.15 loaded [ 11.548913] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 [ 11.548926] saa7134 :04:08.0: PCI INT A - Link[APC1] - GSI 16 (level, low) - IRQ 16 [ 11.548932] saa7133[0]: found at :04:08.0, rev: 209, irq: 16, latency: 32, mmio: 0xfdbfe000 [ 11.548938] saa7133[0]: subsystem: 185b:c900, board: Compro VideoMate T750 [card=139,autodetected] [ 11.549120] saa7133[0]: board init: gpio is 84bf00 [ 11.685878] ACPI: PCI Interrupt Link [APC7] enabled at IRQ 16 [ 11.685885] nvidia :00:05.0: PCI INT A - Link[APC7] - GSI 16 (level, low) - IRQ 16 [ 11.685891] nvidia :00:05.0: setting latency timer to 64 [ 11.686255] NVRM: loading NVIDIA UNIX x86 Kernel Module 180.44 Mon Mar 23 14:59:10 PST 2009 [ 11.712025] saa7133[0]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 [ 11.712036] saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff ff ff ff ff [ 11.712044] saa7133[0]: i2c eeprom 20: 01 40 01 02 02 01 03 01 08 ff 00 87 ff ff ff ff [ 11.712053] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712061] saa7133[0]: i2c eeprom 40: ff d7 00 c4 86 1e 05 ff 02 c2 ff 01 c6 ff 05 ff [ 11.712069] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff cb [ 11.712077] saa7133[0]: i2c eeprom 60: 35 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712085] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712092] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712100] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712108] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712116] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712124] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712132] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712140] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.712148] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.754105] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23 [ 11.754112] HDA Intel :00:10.1: PCI INT B - Link[AAZA] - GSI 23 (level, low) - IRQ 23 [ 11.754168] HDA Intel :00:10.1: setting latency timer to 64 [ 11.780091] tuner 2-0062: chip found @ 0xc4 (saa7133[0]) [ 11.819521] xc2028 2-0062: creating new instance [ 11.819525] xc2028 2-0062: type set to XCeive xc2028/xc3028 tuner [ 11.819535] i2c-adapter i2c-2: firmware: requesting xc3028-v27.fw [ 11.850254] xc2028 2-0062: Error: firmware xc3028-v27.fw not found. [ 11.850262] i2c-adapter i2c-2: firmware: requesting
Re: [linux-dvb] SkyStar HD2 issues, signal sensitivity, etc.
2009/4/12 VDR User user@gmail.com: On Sat, Apr 11, 2009 at 5:47 AM, Dave Lister foc...@gmail.com wrote: 2009/4/11 VDR User user@gmail.com: There is a new mantis tree being uploaded at: http://jusst.de/hg/mantis-v4l Please try this tree. The upload should finish within 2 hours and is using DVB api 5 (aka s2api). RESULTS (using s2 dvb-apps): - scanning DVB-S works - scanning DVB-S2 doesn't work - zapping DVB-S is fast Can you please try a fresh clone of the tree? I believe the fixes have now been applied. Thanks! Ok, I did and it seems fine. I mean for a Linux DVB-S2 card. :) Compared to liplianin driver, only minus is non-working DiSEqC. Because I am using a multiswitch, I had to switch to liplianin. I am sorry, but I'm definitely keeping an eye on your driver as well and will be testing it as it gets updated! For other SkyStar HD2 users, this is a summary as of 2009.04.14: - kernel 2.6.29 + mantis-v4l works (except DiSEqC as far as I can tell) - kernel 2.6.29 + s2-liplianin works just as reliably + DiSEqC Common issues: - zapping DVB-S2 channel causes tuner HW lockup (loss of signal until reboot) - zap DVB-S2 channel = AWFUL ultra-high pitched noise emitted from the card (capacitors or coils?) - makes your head hurt in about 30mins - very poor TS (picture data) quality; signal = 95%, SNR = 70%, STB/TV gives superb picture, but SkyStar/PC picture is corrupted every few seconds, sound glitches, etc. (as if the signal was like 40% on STB) - confirmed in VDR (Xine), MythTV, mplayer. These issues are present with both of my two SkyStar cards, which hopefully eliminates faulty HW. To be frank, I am appalled by the overall quality of PC DVB tuner cards (if HD2 is a representative sample). My last analog Hauppauge PVR-500 (dual tuner card) was better in every aspect. Digital age indeed! I was going to buy new DVB components for my MythTV HTPC, but after these experiences I don't think it is realistic. I'm gonna ask around for other HW recommendations and continue to search for SkyStar tuning tips (I'm stuck with these cards), but I'm losing hope. My old STB with two smarcard readers costs half the price of one SkyStar HD2 and is apparently technically superior. I don't get it. Anyway, sorry for my rambling, just wanted to leave a note for other people who, like me, search mailing lists before buying HW for Linux. I'd like to ask other SkyStar HD2 users if they have similar experiences, especially about the low signal sensitivity. Please, let me know!! Best regards, -- David Lister -- 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] DVB-T USB dib0700 device recommendations?
Hi Guys, [snip] Maybe the VIA usb-hub controller on the board is the problem?! Could be part of the problem. Would be interesting of someone has the same or other experiences with this card or other PCI based cards. Hauppauge ignores all my questions, so I can't recomment products of this manufacturer anyway. Good to know. Thank you! cheers -henrik -- I try to avoid, when ever possible, to participate in such statements. I don't even posses currently and never did previously any Hauppauge device. That you may end up in some m$ support only ring in somewhere on the planet is also very likely too, but we also had very different results in the past even for that. In fact, Hauppauge's GNU/Linux support, let's say during the last five years, is such outstanding well, that it is not even worth to try to start counting, who other OEM can even come close to it. On the higher level, chip manufacturers, we also had very good support from Philips/NXP. What you likely don't see is, that people who did this, did it still in their unpaid and limited free time, but m$ driver only colleagues at work might have helped as well sometimes. And there is still a huge market for v4l-dvb related devices going over the whole globe, it still increases like mad. It is a, count up yourself, N $ market each year. Since a lot of fish is springing out of the water, because of that, we have this NDA problem. So, if you would like to have an argument on this issue, you should be able to count who has contributed _despite_ of that and you don't know. 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: dvb-t reciever card
On 17:05 Wed 08 Apr 2009, phil wrote: I work for a company that is currently developing a new DVB-T receiver PCI card and we would like your help to get a Linux device driver written and into the mainline kernel. The people with DVB-T expertise are on the linux-media@vger.kernel.org mailing list. CC'ing them to see if anyone is interested in working through the NDA process and writing the driver. Cheers, Brandon We plan to release our products specifications when launched, but until then we do require that an NDA is signed by anyone that would be willing to help out. I have briefly looked through some of the past archives of this list and I see that there has been some reference to NDAs from the Linux Foundation, we would be more than happy with using one of these and would appreciate it if someone could provide us with more information on them. Due to the fact that this is a DVB-T card any developer wishing to help should ideally be located in a country which has DVB-T broadcast signals in order to test any equipment which we supply. Please copy me in on any reponses as I believe I'm still awaiting authorisation to be subscribed to this list. -- 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
Reponse from Geniatech Re: X8000A and KWorld ATSC 120
Hi all. As a follow-up to the remote control support issue for the Kworld ATSC 120, Geniatech sent me a very encouraging reply today. Anyone want to take Fang up on his offer? -- Forwarded Message -- Subject: 答复: Technical request regarding the HDTV Thriller X8000A Date: Monday 13 April 2009 From: Fang f...@geniatech.com To: 'Vanessa Ezekowitz' vanessaezekow...@gmail.com Dear Vanessa Ezekowitz: Thanks for your inquiry. My name is Fang, product manager of Geniatech. 1st, we can provide you the remote decoder IC information, including I2C address, r/w API, it is simple, read I2C address every 150ms, and you can get the the key stroke decoding value. 2nd, we have step products and both follow this protocol, so it is useful for all our products. 3rd, we'd like to support you directly from the Geniatech, that card is designed by us. Finnally, I'd like to ask you if you can port more linux drivers if we send you samples and tech informations for our other 2 ATSC products: X8350 and X8550. I will send you more detailed tech information to you about the remote IC whatever your answer is. Best Regards Fang -邮件原件- 发件人: Vanessa Ezekowitz [mailto:vanessaezekow...@gmail.com] 发送时间: 2009年4月10日 5:36 收件人: supp...@geniatech.com 主题: Technical request regarding the HDTV Thriller X8000A THIS IS NOT A USER SUPPORT OR DRIVER REQUEST - WE ALREADY HAVE DRIVERS. THIS IS A PROGRAMMER'S REQUEST FOR TECHNICAL INFORMATION. To whom it may concern, Some time back, I wrote you asking about technical information regarding the Thriller X8000A board. I never received a reply, so I am writing again. I own a card that is a chip-for-chip, wire-for-wire clone of the Thriller X8000A, the Kworld HD PCI 120 (also called the ATSC 120 for short) - it is programmatically indistinguishable from your card. My apologies in advance if I have mistaken which company first made this particular card. Anyway... The manufacturer of my card is refusing to answer my question, claiming that the data I request has been outright lost and can't even be communicated between departments within the company. So now, I turn to you, as the maker of a 100% compatible card. We of the Linux community have successfully written open-source drivers for most of the ATSC120/X8000A's features, except for one: we wish to add support for this card's remote control unit. The Linux Community, whom I am sure you are aware represents a very large, rapidly growing market, cannot in good conscience recommend any cards, Geniatech or otherwise, which lack complete programming information. QUESTION: On my particular card, this appears to be a 20 pin SMD IC near the IR sensor connector. the manufacturer of my cloned card has deliberately removed all the markings from the chip, save for a single green dot of paint, and users who own your card have reported similar circumstances. Is this mystery chip the remote decoder/receiver chip as I suspect? What is the part number of this chip? What I2C address does it occupy? Where can I acquire a datasheet for it? I await your reply. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~vanessa/ Vanessa Ezekowitz vanessaezekow...@gmail.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
[PULL] http://linuxtv.org/hg/awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for cx18: Send correct input routing value to external audio multiplexers This change fixes a bug introduced by a late v4l2_subdev change. Without this fix, Line-in audio and FM radio for CX23418 based cards will be broken. I inspected ivtv and it seems to be unaffected. Regards, Andy diffstat: cx18-audio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) And since the diff is so small: diff -r dba0b6fae413 linux/drivers/media/video/cx18/cx18-audio.c --- a/linux/drivers/media/video/cx18/cx18-audio.c Thu Apr 09 08:21:42 2009 -0300 +++ b/linux/drivers/media/video/cx18/cx18-audio.c Mon Apr 13 20:50:08 2009 -0400 @@ -44,7 +44,7 @@ /* handle muxer chips */ v4l2_subdev_call(cx-sd_extmux, audio, s_routing, - in-audio_input, 0, 0); +(u32) in-muxer_input, 0, 0); err = cx18_call_hw_err(cx, cx-card-hw_audio_ctrl, audio, s_routing, in-audio_input, 0, 0); -- 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] SkyStar HD2 issues, signal sensitivity, etc.
Manu Abraham wrote: Dave Lister wrote: 2009/4/12 VDR User user@gmail.com: On Sat, Apr 11, 2009 at 5:47 AM, Dave Lister foc...@gmail.com wrote: 2009/4/11 VDR User user@gmail.com: There is a new mantis tree being uploaded at: http://jusst.de/hg/mantis-v4l Please try this tree. The upload should finish within 2 hours and is using DVB api 5 (aka s2api). RESULTS (using s2 dvb-apps): - scanning DVB-S works - scanning DVB-S2 doesn't work - zapping DVB-S is fast Can you please try a fresh clone of the tree? I believe the fixes have now been applied. Thanks! Ok, I did and it seems fine. I mean for a Linux DVB-S2 card. :) Compared to liplianin driver, only minus is non-working DiSEqC. Because I am using a multiswitch, I had to switch to liplianin. I am sorry, but I'm definitely keeping an eye on your driver as well and will be testing it as it gets updated! For other SkyStar HD2 users, this is a summary as of 2009.04.14: - kernel 2.6.29 + mantis-v4l works (except DiSEqC as far as I can tell) Diseqc works fine over here, with the VP-1041 and other cards, using the mantis-v4l tree. - kernel 2.6.29 + s2-liplianin works just as reliably + DiSEqC The s2-liplianin tree doesn't use an updated tree for the mantis based devices unfortunately. It is stuck with older changesets of the mantis tree. The s2-liplianin tree contains (ed) ? some clock related changes which were not favourable for the STB0899 demodulator, which is capable of causing potential hardware damage. Common issues: - zapping DVB-S2 channel causes tuner HW lockup (loss of signal until reboot) - zap DVB-S2 channel = AWFUL ultra-high pitched noise emitted from the card (capacitors or coils?) - makes your head hurt in about 30mins - very poor TS (picture data) quality; signal = 95%, SNR = 70%, STB/TV gives superb picture, but SkyStar/PC picture is corrupted every few seconds, sound glitches, etc. (as if the signal was like 40% on STB) - confirmed in VDR (Xine), MythTV, mplayer. These issues are present with both of my two SkyStar cards, which hopefully eliminates faulty HW. To be frank, The cards what i have don't have the issues whatsoever you mention. There could be multiple causes, since the cards that i have don't have the troubles whatsoever you mention. * If you had those changes on your hardware and your card was susceptible to such issues, then that could be a possible reason. * There are quite some hardware pirates, as noted here .. Added the missing link. http://www.twinhan.com/news_071011-1.asp In any of your cases, If you have hardware related issues please contact to your supplier to have it checked/replaced by them. NOTE: Always try to stick with a tree that's a mainline tree or the development tree, rather than tree's with unknown changes. Regards, Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW] v4l2 loopback
On Mon, Apr 13, 2009 at 2:17 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thursday 26 March 2009 19:49:10 Vasily wrote: Hello, please review the new version of v4l2 loopback driver. I fixed up comments to the previous submission, waiting for the new ones :-), reposting for patchwork tool --- 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. Hi Vasily, It's still on my todo list, but I have had very little time. If you still haven't seen a review in two weeks time, then please send me a reminder. Sorry about this, normally I review things like this much sooner but it has been very hectic lately. Regards, Hans Hi Hans, Thanks for updating, driver is still waiting for review, I am glad to here that it is on a todo list :-) Vasily -- 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
BUG when unplugging EyeTV
Hello, I'm hitting a kernel BUG when unplugging my EyeTV on a MacBook Pro. According to the OS X software, it has an XC5000 tuner, AU8522 demodulator, and AU0828 controller; I hear that it is the same as the Hauppage WinTV-HVR-950Q. I'm running Debian sid with a locally-built 2.6.29.1 kernel. The only modifications from the kernel.org vanilla kernel are the addition of v4l-dvb drivers grabbed from hg today and wireless-testing also current as of today. The text of the BUG is pasted below; the BUG is consistently reproducible either if I unplug the device or if I try to rmmod modules (only did this once and not sure rmmod'ing which dvb module actually caused it). I have unfortunately not checked to see how similar the BUG reports end up over different trials. If you need more context, see http://www.contrib.andrew.cmu.edu/~jwatzman/eyetv/ for various parts of dmesg. 1 was taken right after plugging it in; 2 after waiting a few moments for the firmware to upload; 3 after successfully watching TV for about an hour; and 4 after unplugging the device. Let me know if you need more information! Thanks, Josh Watzman [45664.805473] usb 1-3: USB disconnect, address 8 [45664.806201] BUG: unable to handle kernel NULL pointer dereference at 0008 [45664.806209] IP: [802506bb] prepare_to_wait+0x29/0x58 [45664.806222] PGD 7c9ed067 PUD 7c970067 PMD 0 [45664.806229] Oops: 0002 [#1] SMP [45664.806234] last sysfs file: /sys/devices/platform/applesmc.768/light [45664.806238] CPU 0 [45664.806241] Modules linked in: xc5000 tuner au8522 snd_usb_audio snd_usb_lib snd_hwdep au0828 dvb_core videobuf_vmalloc videobuf_core tveeprom v4l2_common radeon drm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 ipv6 binfmt_misc cpufreq_conservative cpufreq_userspace dm_mod cpufreq_stats cpufreq_powersave kvm_intel kvm fuse cpufreq_ondemand acpi_cpufreq freq_table loop firewire_sbp2 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy arc4 snd_seq_oss ecb snd_seq_midi snd_rawmidi ath9k mac80211 snd_seq_midi_event snd_seq rfkill snd_timer snd_seq_device joydev rtc_cmos snd video i2c_i801 rtc_core cfg80211 applesmc appletouch soundcore snd_page_alloc rng_core i2c_core rtc_lib led_class ac battery pcspkr button output evdev input_polldev ext3 jbd mbcache ide_cd_mod cdrom sd_mod ata_generic hid_apple ata_piix libata scsi_mod ide_pci_generic firewire_ohci firewire_core piix crc_itu_t ide_core uhci_hcd ehci_hcd sky2 intel_agp thermal processor fan usbhid hid [45664.806377] Pid: 151, comm: khubd Not tainted 2.6.29.1 #1 MacBookPro2,2 [45664.806382] RIP: 0010:[802506bb] [802506bb] prepare_to_wait+0x29/0x58 [45664.806391] RSP: 0018:88007e0d3c00 EFLAGS: 00010046 [45664.806395] RAX: RBX: 88007e0d3c20 RCX: [45664.806400] RDX: 88007e0d3c38 RSI: 0246 RDI: 8053b8a8 [45664.806404] RBP: 8053b8a8 R08: R09: 2451 [45664.806409] R10: R11: 8800 R12: 0002 [45664.806413] R13: 88004c89 R14: a047f6b8 R15: [45664.806418] FS: () GS:8062() knlGS: [45664.806423] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [45664.806428] CR2: 0008 CR3: 37841000 CR4: 26e0 [45664.806432] DR0: DR1: DR2: [45664.806437] DR3: DR6: 0ff0 DR7: 0400 [45664.806442] Process khubd (pid: 151, threadinfo 88007e0d2000, task 88007e06f990) [45664.806445] Stack: [45664.806448] 880074188190 880074188528 880037909c00 a0468ef5 [45664.806456] 88007e06f990 8025050a 88007e0d3c38 [45664.806464] 88007e0d3c38 88007e0d3c60 8800 880074188190 [45664.806473] Call Trace: [45664.806477] [a0468ef5] ? dvb_net_release+0x60/0xab [dvb_core] [45664.806502] [8025050a] ? autoremove_wake_function+0x0/0x2e [45664.806510] [a0478962] ? au0828_dvb_unregister+0x44/0xa6 [au0828] [45664.806524] [a0477036] ? au0828_usb_disconnect+0x36/0x86 [au0828] [45664.806537] [803b24de] ? usb_unbind_interface+0x5e/0xe5 [45664.806547] [803a2148] ? __device_release_driver+0x83/0xa6 [45664.806555] [803a2243] ? device_release_driver+0x21/0x2d [45664.806561] [803a1874] ? bus_remove_device+0xa8/0xca [45664.806567] [803a0233] ? device_del+0x132/0x16c [45664.806574] [803afd77] ? usb_disable_device+0x7d/0xf4 [45664.806581] [803aba24] ? usb_disconnect+0x89/0x10e [45664.806588] [803ac971] ? hub_thread+0x663/0x1066 [45664.806594] [8020a6c9] ? __switch_to+0xb4/0x399 [45664.806602] [8025050a] ? autoremove_wake_function+0x0/0x2e [45664.806609] [803ac30e] ? hub_thread+0x0/0x1066 [45664.806615]
Re: Problems with Hauppauge HVR 1600 and cx18 driver
On Tue, 2009-03-31 at 06:02 -0400, Brandon Jenkins wrote: Corey and Brandon, I found a race condition between the cx driver and the CX23418 firmware. I have a patch that mitigates the problem here: http://linuxtv.org/hg/~awalls/cx18/rev/9f5f44e0ce6c I think the final form of the patch could be better. However, this patch essentially eliminated any artifacts I was getting playing back digital TV. I also had positive results running mplayer without the -cache command line for both digital and analog captures. I haven't tested on a single processor machine, nor in a multicard setup, but things looked good enough that I thought it ready for test by others. Let me know if it helps or not. Regards, Andy Andy, Based on continued discussions it seems you're still exploring things. I can tell you that the analog captures are still exhibiting artifacts. I'll get to some of the HD captures tonight. Brandon Brandon and Corey, I have a series of changes to improve performance of the cx18 driver in delivering incoming buffers to applications. Please test the code here if you'd like: http://linuxtv.org/hg/~awalls/cx18-perf/ These patches remove all the sleeps from incoming buffer handling (unless your system starts getting very far behind, in which case a fallback strategy starts letting sleeps happen again). If you still have performance problems, there is one more patch I can add, that avoids some sleeps in the new work handler threads that pass empty buffers back out to the firmware. A copy of that patch is here: http://linuxtv.org/hg/~awalls/cx18/rev/b42156ceee11 The trade-off I had to make with all these patches was to have the cx18-driver prefer to spin rather than sleep when waiting for a resource (i.e. the capture stream buffer queues), while handling incoming buffers. This makes the live playback much nicer, but at the expense of CPU cycles and perhaps total system throughput for other things. I'd be interested in how a multicard multistream capture fares. BTW, the above cx18-perf repo is missing a very small patch to fix a recent bug with line-in audio not working. If you need line-in audio to work during testing, a patch is in the main v4l-dvb repo already: http://linuxtv.org/hg/v4l-dvb/rev/d19938a76e7a 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: BUG when unplugging EyeTV
On Mon, Apr 13, 2009 at 9:21 PM, Josh Watzman jwatz...@andrew.cmu.edu wrote: Hello, I'm hitting a kernel BUG when unplugging my EyeTV on a MacBook Pro. According to the OS X software, it has an XC5000 tuner, AU8522 demodulator, and AU0828 controller; I hear that it is the same as the Hauppage WinTV-HVR-950Q. I'm running Debian sid with a locally-built 2.6.29.1 kernel. The only modifications from the kernel.org vanilla kernel are the addition of v4l-dvb drivers grabbed from hg today and wireless-testing also current as of today. The text of the BUG is pasted below; the BUG is consistently reproducible either if I unplug the device or if I try to rmmod modules (only did this once and not sure rmmod'ing which dvb module actually caused it). I have unfortunately not checked to see how similar the BUG reports end up over different trials. If you need more context, see http://www.contrib.andrew.cmu.edu/~jwatzman/eyetv/ for various parts of dmesg. 1 was taken right after plugging it in; 2 after waiting a few moments for the firmware to upload; 3 after successfully watching TV for about an hour; and 4 after unplugging the device. Let me know if you need more information! Thanks, Josh Watzman [45664.805473] usb 1-3: USB disconnect, address 8 [45664.806201] BUG: unable to handle kernel NULL pointer dereference at 0008 [45664.806209] IP: [802506bb] prepare_to_wait+0x29/0x58 [45664.806222] PGD 7c9ed067 PUD 7c970067 PMD 0 [45664.806229] Oops: 0002 [#1] SMP [45664.806234] last sysfs file: /sys/devices/platform/applesmc.768/light [45664.806238] CPU 0 [45664.806241] Modules linked in: xc5000 tuner au8522 snd_usb_audio snd_usb_lib snd_hwdep au0828 dvb_core videobuf_vmalloc videobuf_core tveeprom v4l2_common radeon drm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 ipv6 binfmt_misc cpufreq_conservative cpufreq_userspace dm_mod cpufreq_stats cpufreq_powersave kvm_intel kvm fuse cpufreq_ondemand acpi_cpufreq freq_table loop firewire_sbp2 snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy arc4 snd_seq_oss ecb snd_seq_midi snd_rawmidi ath9k mac80211 snd_seq_midi_event snd_seq rfkill snd_timer snd_seq_device joydev rtc_cmos snd video i2c_i801 rtc_core cfg80211 applesmc appletouch soundcore snd_page_alloc rng_core i2c_core rtc_lib led_class ac battery pcspkr button output evdev input_polldev ext3 jbd mbcache ide_cd_mod cdrom sd_mod ata_generic hid_apple ata_piix libata scsi_mod ide_pci_generic firewire_ohci firewire_core piix crc_itu_t ide_core uhci_hcd ehci_hcd sky2 intel_agp thermal processor fan usbhid hid [45664.806377] Pid: 151, comm: khubd Not tainted 2.6.29.1 #1 MacBookPro2,2 [45664.806382] RIP: 0010:[802506bb] [802506bb] prepare_to_wait+0x29/0x58 [45664.806391] RSP: 0018:88007e0d3c00 EFLAGS: 00010046 [45664.806395] RAX: RBX: 88007e0d3c20 RCX: [45664.806400] RDX: 88007e0d3c38 RSI: 0246 RDI: 8053b8a8 [45664.806404] RBP: 8053b8a8 R08: R09: 2451 [45664.806409] R10: R11: 8800 R12: 0002 [45664.806413] R13: 88004c89 R14: a047f6b8 R15: [45664.806418] FS: () GS:8062() knlGS: [45664.806423] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [45664.806428] CR2: 0008 CR3: 37841000 CR4: 26e0 [45664.806432] DR0: DR1: DR2: [45664.806437] DR3: DR6: 0ff0 DR7: 0400 [45664.806442] Process khubd (pid: 151, threadinfo 88007e0d2000, task 88007e06f990) [45664.806445] Stack: [45664.806448] 880074188190 880074188528 880037909c00 a0468ef5 [45664.806456] 88007e06f990 8025050a 88007e0d3c38 [45664.806464] 88007e0d3c38 88007e0d3c60 8800 880074188190 [45664.806473] Call Trace: [45664.806477] [a0468ef5] ? dvb_net_release+0x60/0xab [dvb_core] [45664.806502] [8025050a] ? autoremove_wake_function+0x0/0x2e [45664.806510] [a0478962] ? au0828_dvb_unregister+0x44/0xa6 [au0828] [45664.806524] [a0477036] ? au0828_usb_disconnect+0x36/0x86 [au0828] [45664.806537] [803b24de] ? usb_unbind_interface+0x5e/0xe5 [45664.806547] [803a2148] ? __device_release_driver+0x83/0xa6 [45664.806555] [803a2243] ? device_release_driver+0x21/0x2d [45664.806561] [803a1874] ? bus_remove_device+0xa8/0xca [45664.806567] [803a0233] ? device_del+0x132/0x16c [45664.806574] [803afd77] ? usb_disable_device+0x7d/0xf4 [45664.806581] [803aba24] ? usb_disconnect+0x89/0x10e [45664.806588] [803ac971] ? hub_thread+0x663/0x1066 [45664.806594] [8020a6c9] ?
Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
On Sun, 05 Apr 2009 20:22:33 +0200
hermann pitton hermann-pit...@arcor.de wrote:
Hi,
Am Samstag, den 04.04.2009, 17:20 +0200 schrieb Ra.M.:
hermann pitton ha scritto:
Am Samstag, den 04.04.2009, 02:45 +0200 schrieb hermann pitton:
Hi Ralph,
Am Freitag, den 03.04.2009, 20:49 + schrieb Ralph:
ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card
Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135
Video
Broadcast Decoder (rev d1)
Works perfectly with kernel 2.6.28.4 (or older).
Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now,
at
boot
time, I get the message:
IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
Signal strength is very low and Kaffeine is unable to tune in any
channel.
Same problem with kernel 2.6.29.1
-
Messages from /var/log/dmesg
saa7134 :03:0a.0: PCI INT A - Link[APC3] - GSI 18 (level, low) -
\
IRQ 18
saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32,
mmio: \
0xfdefe000
saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \
[card=111,autodetected]
saa7133[0]: board init: gpio is 0
IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2
92
saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff
ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff
tuner' 2-004b: chip found @ 0x96 (saa7133[0])
tda829x 2-004b: setting tuner address to 61
tda829x 2-004b: type set to tda8290+75a
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
dvb_init() allocating 1 frontend
DVB: registering new adapter (saa7133[0])
DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)...
tda1004x: setting up plls for 48MHz sampling clock
tda1004x: timeout waiting for DSP ready
tda1004x: found firmware revision 0 -- invalid
tda1004x: trying to boot from eeprom
tda1004x: timeout waiting for DSP ready
tda1004x: found firmware revision 0 -- invalid
tda1004x: waiting for firmware upload...
saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw
tda1004x: found firmware revision 29 -- ok
saa7134 ALSA driver for DMA sound loaded
IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1
thanks for your report, as announced previously, I unfortunately did not
have time to run with latest always ... (guess why ...)
The driver always worked with shared IRQs, if not, it was always a
limitation of certain hardware or mostly in some combination with binary
only drivers.
If the above should be the case in general now, and not only caused by
some blacklist, no print out in that direction, the driver is pretty
broken again.
I for sure don't have all for last months, but that
IRQF_DISABLED is not guaranteed on shared IRQs for sure does not come
from us here.
Do use something unusual like pollirq or something?
We only have in saa7134-core.c
/* initialize hardware #1 */
saa7134_board_init1(dev);
saa7134_hwinit1(dev);
/* get irq */
err = request_irq(pci_dev-irq, saa7134_irq,
IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
if (err 0) {
printk(KERN_ERR %s: can't get IRQ %d\n,
dev-name,pci_dev-irq);
goto fail3;
}
and in saa7134-alsa.c
err = request_irq(dev-pci-irq, saa7134_alsa_irq,
IRQF_SHARED | IRQF_DISABLED, dev-name,
(void*) dev-dmasound);
if (err 0) {
Re: BUG when unplugging EyeTV
Hello Josh, Thanks for the bug report. Robert Krakora reported the same stack trace to me off-list over the weekend. I've been tied up with some family business, but I intend to dig into it deeper this weekend. No problem, take your time. I was quite pleased when the DVB worked on the stock kernel and even more pleased when the analog worked with the current hg tree. Thank you all for your work on these drivers. I didn't know that Elgato had a 950q clone (I did work on the original Elgato EyeTV device for Linux). Could you please send me the output of lsusb -v so I can confirm precisely which device it is a clone of? I'm not 100% sure it's a clone of that card, but everything seems to match. The instructions for the 950q firmware on the wiki are what originally allowed me to get it working. The lsusb is quite long -- you can get it at http://www.contrib.andrew.cmu.edu/~jwatzman/eyetv/lsusb and I've also uploaded a screenshot of what the OS X software says the device is at http://www.contrib.andrew.cmu.edu/~jwatzman/eyetv/eyetv.png if that helps too. Josh Watzman -- 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: About the radio-si470x driver for I2C interface
On 4/14/2009 3:35 AM, Tobias Lorenz wrote:
Hi Joonyoung,
I have some problem. There is codes for usb in radio-si470x-common.c file.
Hrm, if it cannot be removed, maybe it seems to seperate using ifdef.
What do you think about this?
I moved some more functions from radio-si470x-common.c file to
radio-si470x-usb.c:
- si470x_start
- si470x_stop
- si470x_fops_open
- si470x_fops_release
Now the common file should be free of any USB specific components.
Please have a look at
http://linuxtv.org/hg/~tlorenz/v4l-dvb/
Maybe we can move something back later for optimization. But for now, it
should be okay.
Bye,
Toby
Hi Tobias,
I have some questions.
The i2c device is connected always unlike the usb device, so it doesn't
use disconnected and disconnect_lock of struct si470x_device, these are
usb specific.
Unlike you say, si470x_start and si470x_stop functions exist yet in
radio-si470x-common.c.
I know from datasheet that software should wait for the powerup time(110ms)
after power up, and i verified it at the si4709 device using i2c interface,
but there is not at your implementation.
I wonder above things, and i send you the patch to fix make warning and build
errors, and for easy work.
=
Fix compile warnings and errors of radio-si470x-i2c
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
linux/drivers/media/radio/si470x/Kconfig |2 +-
linux/drivers/media/radio/si470x/Makefile |4 +-
.../drivers/media/radio/si470x/radio-si470x-i2c.c | 153 +---
linux/drivers/media/radio/si470x/radio-si470x.h|5 +-
4 files changed, 74 insertions(+), 90 deletions(-)
diff --git a/linux/drivers/media/radio/si470x/Kconfig
b/linux/drivers/media/radio/si470x/Kconfig
index 3172e1a..07ac2d3 100644
--- a/linux/drivers/media/radio/si470x/Kconfig
+++ b/linux/drivers/media/radio/si470x/Kconfig
@@ -34,4 +34,4 @@ config I2C_SI470X
computer's I2C port.
To compile this driver as a module, choose M here: the
- module will be called radio-si470x-i2c.
+ module will be called radio-i2c-si470x.
diff --git a/linux/drivers/media/radio/si470x/Makefile
b/linux/drivers/media/radio/si470x/Makefile
index 945e7b1..a4bba94 100644
--- a/linux/drivers/media/radio/si470x/Makefile
+++ b/linux/drivers/media/radio/si470x/Makefile
@@ -3,7 +3,7 @@
#
radio-si470x-objs := radio-si470x-usb.o radio-si470x-common.o
-radio-si470x-i2c-objs := radio-si470x-i2c.o radio-si470x-common.o
+radio-i2c-si470x-objs := radio-si470x-i2c.o radio-si470x-common.o
obj-$(CONFIG_USB_SI470X) += radio-si470x.o
-obj-$(CONFIG_I2C_SI470X) += radio-si470x-i2c.o
+obj-$(CONFIG_I2C_SI470X) += radio-i2c-si470x.o
diff --git a/linux/drivers/media/radio/si470x/radio-si470x-i2c.c
b/linux/drivers/media/radio/si470x/radio-si470x-i2c.c
index 7058b84..27a0691 100644
--- a/linux/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/linux/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -57,14 +57,9 @@ MODULE_PARM_DESC(radio_nr, Radio Nr);
*/
int si470x_get_register(struct si470x_device *radio, int regnr)
{
- int retval;
+ /* TODO */
- retval = 0; /* TODO */
-
- if (retval = 0)
- radio-registers[regnr] = 0; /* TODO */
-
- return (retval 0) ? -EINVAL : 0;
+ return 0;
}
@@ -73,13 +68,9 @@ int si470x_get_register(struct si470x_device *radio, int
regnr)
*/
int si470x_set_register(struct si470x_device *radio, int regnr)
{
- int retval;
-
- radio-registers[regnr] = 0; /* TODO */
+ /* TODO */
- retval = 0; /* TODO */
-
- return (retval 0) ? -EINVAL : 0;
+ return 0;
}
@@ -88,16 +79,9 @@ int si470x_set_register(struct si470x_device *radio, int
regnr)
*/
int si470x_get_all_registers(struct si470x_device *radio)
{
- int retval;
- unsigned char regnr;
-
- retval = 0; /* TODO */
+ /* TODO */
- if (retval = 0)
- for (regnr = 0; regnr RADIO_REGISTER_NUM; regnr++)
- radio-registers[regnr] = 0; /* TODO */
-
- return (retval 0) ? -EINVAL : 0;
+ return 0;
}
@@ -106,17 +90,9 @@ int si470x_get_all_registers(struct si470x_device *radio)
*/
int si470x_get_rds_registers(struct si470x_device *radio)
{
- int retval;
- int size;
- unsigned char regnr;
-
- retval = /* TODO */
+ /* TODO */
- if (retval = 0)
- for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++)
- radio-registers[STATUSRSSI + regnr] = 0; /* TODO */
-
- return (retval 0) ? -EINVAL : 0;
+ return 0;
}
@@ -131,26 +107,15 @@ int si470x_get_rds_registers(struct si470x_device *radio)
int si470x_fops_open(struct file *file)
{
struct si470x_device *radio = video_drvdata(file);
- int retval;
+ int retval = 0;
lock_kernel();
Re: tuner-core i2c address range check: time to remove them?
Hans Verkuil wrote: On Sunday 29 March 2009 22:53:01 Hans Verkuil wrote: Hi all, The tuner-core.c source contains this warning since 2.6.24: tuner_warn(Support for tuners in i2c address range 0x64 thru 0x6f\n); tuner_warn(will soon be dropped. This message indicates that your\n); tuner_warn(hardware has a %s tuner at i2c address 0x%02x.\n, t-name, t-i2c-addr); tuner_warn(To ensure continued support for your device, please\n); tuner_warn(send a copy of this message, along with full dmesg\n); tuner_warn(output to v4l-dvb-maintai...@linuxtv.org\n); tuner_warn(Please use subject line: \obsolete tuner i2c address.\\n); tuner_warn(driver: %s, addr: 0x%02x, type: %d (%s)\n, t-i2c-adapter-name, t-i2c-addr, t-type, t-name); Isn't it time to remove these i2c addresses? I don't believe we ever had a real tuner at such an address. With the ongoing v4l2_subdev conversion I need to do a bit of cleanup in tuner-core.c as well, so it would be a good time for me to combine it (and it gets rid of an ugly cx88 hack in tuner-core.c as well). Regards, Hans Mike, please let me know if I can remove this! Hans, The warning message can be removed now, but please note that i2c address 0x64 *is* a valid i2c address for a tuner. I believe that 0x65 thru 0x6f can be removed. Regards, Mike -- 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
