Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Thank you for your comment.
BTW, what should I do if I would rather use external ISP device than
OMAP3 internal ISP feature?
You said that you just have raw sensors by now, so you mean this patch
is not verified working with some ISP modules?
I'm testing your patch on my own omap3 target board with NEC ISP...but
unfortunately not working yet ;(
I should try more harder. more research is needed :)
Cheers,
On Thu, Feb 12, 2009 at 4:09 PM, Sakari Ailus
wrote:
> DongSoo Kim wrote:
>>
>> Hello.
>
> Hi, and thanks for the comments!
>
>> +static int omap34xxcam_open(struct inode *inode, struct file *file)
>> +{
>>
>>
>>
>> + if (atomic_inc_return(&vdev->users) == 1) {
>> + isp_get();
>> + if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
>> +
>> OMAP34XXCAM_SLAVE_POWER_ALL))
>> + goto out_slave_power_set_standby;
>> + omap34xxcam_slave_power_set(
>> + vdev, V4L2_POWER_STANDBY,
>> + OMAP34XXCAM_SLAVE_POWER_SENSOR);
>> + omap34xxcam_slave_power_suggest(
>> + vdev, V4L2_POWER_STANDBY,
>> + OMAP34XXCAM_SLAVE_POWER_LENS);
>> + }
>>
>>
>> I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
>> device is really necessary.
>>
>> Because if that makes sensor device in standby mode, we do S_FMT and
>> bunch of V4L2 APIs while the camera module is in standby mode.
>>
>> In most cases of "sensor + ISP" SOC camera modules, I2C command is not
>> working while the camera module is in standby mode.
>
> I guess that applies to most sensors.
>
>> Following the camera interface source code, sensor goes down to
>> standby mode until VIDIOC_STREAMON is called.
>>
>> If this power up timing depends on sensor device, then I think we need
>> a conditional power on sequence.
>
> You're right, there's something wrong with the slave power handling. :)
>
> We were thinking that the sensor (or any slave) power management (current
> on, off and standby) could be replaced by four commands: open, close,
> streamon and streamoff. The slave could decide by itself what its real power
> state is. IMO direct power management doesn't belong to the camera driver
> which doesn't drive any hardware anyway.
>
>> As you defined slave devices as SENSOR, LENS, FLASH, then how about
>> making a new slave category like "ISP" for "sensor+ISP" SOC modules?
>
> I currently have just raw sensors. It'd be nice to keep the interface for
> smart sensors the same, though. You still need for a receiver for the image
> data, sometimes called the camera controller. That would be the same than
> the ISP but without fancy features.
>
> Cheers,
>
> --
> Sakari Ailus
> sakari.ai...@maxwell.research.nokia.com
>
--
Dong Soo, Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
DongSoo Kim wrote:
Hello.
Hi, and thanks for the comments!
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
+ if (atomic_inc_return(&vdev->users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+ OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of "sensor + ISP" SOC camera modules, I2C command is not
working while the camera module is in standby mode.
I guess that applies to most sensors.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
You're right, there's something wrong with the slave power handling. :)
We were thinking that the sensor (or any slave) power management
(current on, off and standby) could be replaced by four commands: open,
close, streamon and streamoff. The slave could decide by itself what its
real power state is. IMO direct power management doesn't belong to the
camera driver which doesn't drive any hardware anyway.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like "ISP" for "sensor+ISP" SOC modules?
I currently have just raw sensors. It'd be nice to keep the interface
for smart sensors the same, though. You still need for a receiver for
the image data, sometimes called the camera controller. That would be
the same than the ISP but without fancy features.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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] Added support for AVerMedia Cardbus Hybrid remote control
Added support for I2C device at address 0x40 and subaddress 0x0d/0x0b
that provides remote control key reading support for AVerMedia Cardbus
Hybrid card, possibly for other AVerMedia Cardbus cards.
The I2C address 0x40 doesn't like the SAA7134's 0xfd quirk, so it was
disabled.
Signed-off-by: Oldřich Jedlička
---
diff -r 66e0b01971de -r 2b8e5fc5b41f linux/drivers/media/common/ir-keymaps.c
--- a/linux/drivers/media/common/ir-keymaps.c Thu Jan 22 19:27:07 2009 +0100
+++ b/linux/drivers/media/common/ir-keymaps.c Thu Jan 22 19:28:09 2009 +0100
@@ -154,6 +154,65 @@
};
EXPORT_SYMBOL_GPL(ir_codes_avermedia_m135a);
+/* Oldrich Jedlicka */
+IR_KEYTAB_TYPE ir_codes_avermedia_cardbus[IR_KEYTAB_SIZE] = {
+ [ 0x00 ] = KEY_POWER,
+ [ 0x01 ] = KEY_TUNER, /* TV/FM */
+ [ 0x03 ] = KEY_TEXT,/* Teletext */
+ [ 0x04 ] = KEY_EPG,
+ [ 0x05 ] = KEY_1,
+ [ 0x06 ] = KEY_2,
+ [ 0x07 ] = KEY_3,
+ [ 0x08 ] = KEY_AUDIO,
+ [ 0x09 ] = KEY_4,
+ [ 0x0a ] = KEY_5,
+ [ 0x0b ] = KEY_6,
+ [ 0x0c ] = KEY_ZOOM,/* Full screen */
+ [ 0x0d ] = KEY_7,
+ [ 0x0e ] = KEY_8,
+ [ 0x0f ] = KEY_9,
+ [ 0x10 ] = KEY_PAGEUP, /* 16-CH PREV */
+ [ 0x11 ] = KEY_0,
+ [ 0x12 ] = KEY_INFO,
+ [ 0x13 ] = KEY_AGAIN, /* CH RTN - channel return */
+ [ 0x14 ] = KEY_MUTE,
+ [ 0x15 ] = KEY_EDIT,/* Autoscan */
+ [ 0x17 ] = KEY_SAVE,/* Screenshot */
+ [ 0x18 ] = KEY_PLAYPAUSE,
+ [ 0x19 ] = KEY_RECORD,
+ [ 0x1a ] = KEY_PLAY,
+ [ 0x1b ] = KEY_STOP,
+ [ 0x1c ] = KEY_FASTFORWARD,
+ [ 0x1d ] = KEY_REWIND,
+ [ 0x1e ] = KEY_VOLUMEDOWN,
+ [ 0x1f ] = KEY_VOLUMEUP,
+ [ 0x22 ] = KEY_SLEEP, /* Sleep */
+ [ 0x23 ] = KEY_ZOOM,/* Aspect */
+ [ 0x26 ] = KEY_SCREEN, /* Pos */
+ [ 0x27 ] = KEY_ANGLE, /* Size */
+ [ 0x28 ] = KEY_SELECT, /* Select */
+ [ 0x29 ] = KEY_BLUE,/* Blue/Picture */
+ [ 0x2a ] = KEY_BACKSPACE, /* Back */
+ [ 0x2b ] = KEY_MEDIA, /* PIP (Picture-in-picture) */
+ [ 0x2c ] = KEY_DOWN,
+ [ 0x2e ] = KEY_DOT,
+ [ 0x2f ] = KEY_TV, /* Live TV */
+ [ 0x32 ] = KEY_LEFT,
+ [ 0x33 ] = KEY_CLEAR, /* Clear */
+ [ 0x35 ] = KEY_RED, /* Red/TV */
+ [ 0x36 ] = KEY_UP,
+ [ 0x37 ] = KEY_HOME,/* Home */
+ [ 0x39 ] = KEY_GREEN, /* Green/Video */
+ [ 0x3d ] = KEY_YELLOW, /* Yellow/Music */
+ [ 0x3e ] = KEY_OK, /* Ok */
+ [ 0x3f ] = KEY_RIGHT,
+ [ 0x40 ] = KEY_NEXT,/* Next */
+ [ 0x41 ] = KEY_PREVIOUS,/* Previous */
+ [ 0x42 ] = KEY_CHANNELDOWN, /* Channel down */
+ [ 0x43 ] = KEY_CHANNELUP/* Channel up */
+};
+EXPORT_SYMBOL_GPL(ir_codes_avermedia_cardbus);
+
/* Attila Kondoros */
IR_KEYTAB_TYPE ir_codes_apac_viewcomp[IR_KEYTAB_SIZE] = {
diff -r 66e0b01971de -r 2b8e5fc5b41f linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cThu Jan 22 19:27:07 2009 +0100
+++ b/linux/drivers/media/video/ir-kbd-i2c.cThu Jan 22 19:28:09 2009 +0100
@@ -16,6 +16,8 @@
* Henry Wong
* Mark Schultz
* Brian Rogers
+ * modified for AVerMedia Cardbus by
+ * Oldrich Jedlicka
*
* 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
@@ -217,6 +219,46 @@
return 1;
}
+static int get_key_avermedia_cardbus(struct IR_i2c *ir,
+u32 *ir_key, u32 *ir_raw)
+{
+ unsigned char subaddr, key, keygroup;
+ struct i2c_msg msg[] = {{.addr=ir->c.addr, .flags=0, .buf=&subaddr,
+ .len = 1},
+ {.addr=ir->c.addr, .flags=I2C_M_RD, .buf=&key,
+ .len = 1}};
+ subaddr = 0x0d;
+ if (2 != i2c_transfer(ir->c.adapter, msg, 2)) {
+ dprintk(1, "read error\n");
+ return -EIO;
+ }
+
+ if (key == 0xff)
+ return 0;
+
+ subaddr = 0x0b;
+ msg[1].buf = &keygroup;
+ if (2 != i2c_transfer(ir->c.adapter, msg, 2)) {
+ dprintk(1, "read error\n");
+ return -EIO;
+ }
+
+ if (keygroup == 0xff)
+ return 0;
+
+ dprintk(1, "read key 0x%02x/0x%02x\n", key, keygroup);
+ if (keygroup < 2 || keygroup > 3) {
+ /* Only a warning */
+ dprintk(1, "warning: invalid key group 0x%02x for key 0x%02x\n",
+ keygroup, key);
+ }
+ key |= (keygroup & 1) << 6;
+
+ *ir_key =
Re: [PATCH][RESEND 2] Added support for AVerMedia Cardbus Hybrid remote control
On Wed, 2009-02-11 at 15:47 +0100, Oldrich Jedlicka wrote: > Hi, > > please have a look at the attached patch. > > Signed-off-by: Oldřich Jedlička > > Thanks, > Oldřich. Hello, Oldrich I tried to find your patch(this and from 1 Feb) on patchwork.kernel.org and failed :( Probably this tool doesn't handle attachment patches. So, there is a good hint - it's better to inline text in the body of the emai. It's easier to review them and they didn't lost cos patchwork.kernel.org catches them. You can find instructions in linux/Documentation/email-clients.txt how to use email-client in this way. -- Best regards, Klimov Alexey -- 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/~dougsland/v4l2-em28xx
Hi Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l2-em28xx for the following: - em28xx: Coding style fixes and a typo correction - em28xx: Add DVC 101 model to Pinnacle Dazzle description - em28xx-audio: Add macros EM28XX_START_AUDIO / EM28XX_STOP_AUDIO - em28xx-audio: replace printk with em28xx_errdev - em28xx-audio: Add lock for users - em28xx-audio: Add spinlock for trigger - em28xx: Fix for em28xx audio startup - em28xx: Fix for em28xx memory leak and function rename - em28xx: remove bad check (changeset a31c595188af) Thanks, Douglas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
On Wed, Feb 11, 2009 at 05:43:29AM -0200, Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 21:50:16 -0600 > David Engel wrote: > > MythTV eventually worked too, but I had to do the > > "unload/reload modules and run tvtime" procedure I reported earlier > > when I tried Hans' kworld tree. > > Maybe this is a race condition I have here with tda1004x. With tda1004x, the > i2c > bus shouldn't be used by any other device during the firmware transfers, > otherwise the firmware load will fail, and tda1004x goes into an unstable > state. With this device, it even affects all subsequent i2c acesses. The only > alternative to recover tda1004x is to reboot the card (e. g. with my cardbus > device, I have to physically remove it and re-insert). > > What happens is that some softwares (including udev) open the device, and send > some VIDIOC_G_TUNER in order to check some tuner characteristics. However, > this > command generates some i2c transfers, to retrieve signal strength. If this > happens while the firmware is being loaded, the bug occurs. > > In order to fix, a careful review of all locks on the driver is needed. We > will > likely need to change the demod interface for the boards that have this > trouble, in order to be aware of when a firmware transfer started. > > This lock review is currently on my TODO list. > > To be sure that this is the case, could you please add this on > your /etc/modprobe (or at a file inside /etc/modprobe.d): > > options nxt200x debug=1 > options tuner-simple debug=1 > options tuner debug=1 > options dvb-core frontend_debug=1 > > And test again, sending us the produced logs when the device works and when it > breaks. I guess we'll discover some tuner dmesg's in the middle of the > firmware > load sequence. I will do this, but it will be tomorrow evening before I can get to it. David -- David Engel da...@istwok.net -- 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-usb-cinergyT2
Thierry Merle wrote: > another user has got the same problem, except that the led still lights up. > Can you tell us what it the firmware version in your device? > You can see it by doing lsusb -vvv, for the Cinergy T2 entry this is the > "bcdDevice" line. > I have the 1.06 firmware version and it works. > Cheers, > Thierry > Hi Thierry, thanks for your message! I just tried again and miraculously enough it seems to work now. In the meantime I only did a kernel upgrade to 2.6.28.4. So maybe that was the trick. :) Nonetheless I attach the lsusb output for further reference, my firmware version though seems to be the same as yours: 1.06. Cheers, Johannes Bus 005 Device 002: ID 0ccd:0038 TerraTec Electronic GmbH Cinergy T^2 DVB-T Receiver Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0038 Cinergy T^2 DVB-T Receiver bcdDevice1.06 iManufacturer 1 TerraTec GmbH iProduct2 Cinergy T² iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 476mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 3 Highspeed Bulk Transfer Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 bNumConfigurations 1
Re: dvb-usb-cinergyT2
Hello Johannes, Johannes Engel wrote: > Hello! > > Switching to the new kernel 2.6.28 including the new driver for my Terratec > Cinergy T² made the thing almost unusable. > Neither mplayer nor scan resp. w_scan is able to tune the card anymore, not > even the led lights up anymore. Sometimes tzap manages to get out a proper > signal, but not reliably. > > The kernel logs says the following: > > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > deinitialized and disconnected. > usbcore: deregistering interface driver cinergyT2 > usb 5-1: new high speed USB device using ehci_hcd and address 13 > usb 5-1: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid > maxpacket 64 > usb 5-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid > maxpacket 64 > usb 5-1: configuration #1 chosen from 1 choice > usb 5-1: New USB device found, idVendor=0ccd, idProduct=0038 > usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 5-1: Product: Cinergy T� > usb 5-1: Manufacturer: TerraTec GmbH > dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in warm > state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. > DVB: registering new adapter (TerraTec/qanu USB2.0 Highspeed DVB-T Receiver) > DVB: registering adapter 0 frontend 0 (TerraTec/qanu USB2.0 Highspeed DVB-T > Receiver)... > input: IR-receiver inside an USB DVB receiver as > /devices/pci:00/:00:1d.7/usb5/5-1/input/input17 > dvb-usb: schedule remote query interval to 50 msecs. > dvb-usb: TerraTec/qanu USB2.0 Highspeed DVB-T Receiver successfully > initialized and connected. > usbcore: registered new interface driver cinergyT2 > > Do you need any further information? Please CC me, since I am not subscribed > to the list. > another user has got the same problem, except that the led still lights up. Can you tell us what it the firmware version in your device? You can see it by doing lsusb -vvv, for the Cinergy T2 entry this is the "bcdDevice" line. I have the 1.06 firmware version and it works. Cheers, Thierry -- 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] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Wed Feb 11 19:00:04 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10516:b07848302e6c gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc4-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc4-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc4-armv5-omap2: OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc4-i686: WARNINGS linux-2.6.16.61-m32r: ERRORS linux-2.6.17.14-m32r: ERRORS linux-2.6.18.8-m32r: ERRORS linux-2.6.19.5-m32r: ERRORS linux-2.6.20.21-m32r: ERRORS linux-2.6.21.7-m32r: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc4-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc4-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc4-powerpc64: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc4-x86_64: WARNINGS fw/apps: OK spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc4): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.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
Problem with TwinHan PCI-Sat Card
Hallo, my configuration is * Fujitsu Siemens HTPC * MythDora 5.0(FC 8) * TwinHan PCI-Sat * Technisat Multytenne(4 Satelite positions 13.0 19.2,23.5, 28) dual This mulitytenne is once connected to a technisat receiver and once to the HTPC. I can watch on the receiver, but I did not success with my htpc so far. The card is recognized in mythtv-setup, but it cant determine its parameters, so I tried to use it manually, first. I got installed 2 tv cards in my HTPC, I am concentrating on the Twinhan Vision Plus DVB In my /etc/modprobe.conf there is not yet anything mentioned about my dvb card ls /dev/dvb/adapter0/ shows ca0 demux0 dvr0 frontend0 net0 I successfully generated a channels.conf with valid and real channels. When I run [myt...@localhost szap]$ ./szap -a 0 -r N24 reading channels from file '/home/mythtv/.szap/channels.conf' zapping to 17 'N24': sat 0, frequency = 12640 MHz V, symbolrate 2200, vpid = 0x03ff, apid = 0x0400 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' FE_SET_VOLTAGE failed: Input/output error status 1f | signal fffe | snr fffe | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal fffe | snr 22ef | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal 3d00 | snr 22f3 | ber fffe | unc fffe | FE_HAS_LOCK ... The error message about FE_SET_VOLTAGE does sometimes appear if i try then/during mplayer /dev/dvb/adapter0/dvr0 I get nothing, dvr does not output any byte Relevant modules loaded are saa7134_alsa 14689 1 tda1004x 17477 1 saa7134_dvb1 0 videobuf_dvb8517 1 saa7134_dvb dst_ca 14913 1 tuner_simple 15953 2 tuner_types17857 1 tuner_simple tda988713509 1 tda829015685 0 dst27593 2 dst_ca dvb_bt8xx 17605 0 dvb_core 68673 5 saa7134_dvb,videobuf_dvb,dst_ca,dst,dvb_bt8xx saa7134 128789 2 saa7134_alsa,saa7134_dvb bt878 12793 2 dst,dvb_bt8xx tuner 26249 0 bttv 152661 2 dvb_bt8xx,bt878 videodev 31425 3 saa7134,tuner,bttv The important passages of dmesg look like bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :01:0b.0[A] -> GSI 16 (level, low) -> IRQ 16 bttv0: Bt878 (rev 17) at :01:0b.0, irq: 16, latency: 32, mmio: 0xfdcff000 bttv0: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 bttv0: using: Twinhan DST + clones [card=113,autodetected] bttv0: gpio: en=, out= in=00f5fffd [init] input: i2c IR (Hauppauge) as /class/input/input8 ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-001a/ir0 [bt878 #0 [hw]] bttv0: tuner absent bttv0: add subdevice "dvb0" bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). ACPI: PCI Interrupt :01:0b.1[A] -> GSI 16 (level, low) -> IRQ 16 bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. bt878(0): Bt878 (rev 17) at 01:0b.1, irq: 16, latency: 32, memory: 0xfdcfe000 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt :01:04.0[A] -> GSI 19 (level, low) -> IRQ 19 saa7134[0]: found at :01:04.0, rev: 1, irq: 19, latency: 32, mmio: 0xfddff000 saa7134[0]: subsystem: 021a:0001, board: Medion 7134 [card=12,insmod option] saa7134[0]: board init: gpio is 0 DVB: registering new adapter (bttv0) tuner' 2-0043: chip found @ 0x86 (saa7134[0]) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner' 2-0061: chip found @ 0xc2 (saa7134[0]) saa7134[0]: i2c eeprom 00: a0 12 02 00 54 20 08 00 43 43 28 0c 00 52 20 12 saa7134[0]: i2c eeprom 10: 00 87 82 0f ff 20 2a 00 00 50 12 00 00 18 0a 10 saa7134[0]: i2c eeprom 20: 01 00 00 02 02 03 01 00 06 ad 00 10 02 51 00 08 saa7134[0]: i2c eeprom 30: 01 18 48 07 03 00 00 0c d2 00 00 10 00 00 12 3c saa7134[0]: i2c eeprom 40: 60 00 00 c0 82 10 00 00 00 00 01 58 40 1b 02 8d saa7134[0]: i2c eeprom 50: 7d 56 65 3f 00 5b 06 02 00 00 04 00 0c 00 04 00 saa7134[0]: i2c eeprom 60: 2b a6 7d 38 2b d4 d3 5b 3a 51 e5 5e c6 87 f2 ff saa7134[0]: i2c eeprom 70: ff a6 2a 58 3a 5b 13 86 b2 58 1a d4 d3 58 5a 5d saa7134[0]: i2c eeprom 80: 02 22 50 1f 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 saa7134[0]: i2c eeprom 90: 16 7d 28 1c 41 18 48 87 f3 00 01 8d f3 00 01 50 saa7134[0]: i2c eeprom a0: 22 58 12 7f 60 00 91 5e 18 ff ff a6 7d da d8 79 saa7134[0]: i2c eeprom b0: 29 52 96 d4 d3 5b 3a ad 2b 41 84 22 a6 58 66 00 saa7134[0]: i2c eeprom c0: 93 26 29 a6 2a 58 3a 5b 13 a6 29 58 1a 61 2b d4 saa7134[0]: i2c eeprom d0: d3 49 82 8f ba 49 82 8f f2 00 01 5d 12 22 7e 1f saa7134[0]: i2c eeprom e0: 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 16 7d 28 1c saa7134[0]: i2c eeprom f0: 41 18 48 87 f3 00 01 8d f3 00 01 50 22 60 29 7f saa7134[0] Cant determine tuner type 1000 from EEPROM saa7134[0] Tuner type is 63 tuner
Aw: Re: Driver for this DVB-T tuner?
Antti wrote: > Still old firmware. What md5sum says? > > [r...@localhost ~]# md5sum /lib/firmware/dvb-usb-af9015.fw > dccbc92c9168cc629a88b34ee67ede7b /lib/firmware/dvb-usb-af9015.fw Same as yours: $ md5sum /lib/firmware/dvb-usb-af9015.fw dccbc92c9168cc629a88b34ee67ede7b dvb-usb-af9015.fw Do I have to enable HOTPLUG_PCI additionally to HOTPLUG for kernel? -- 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: tt3200 and lnb switch
Pierre Gronlier wrote: > Hello, > > I'm using the v4l-dvb driver from this http://linuxtv.org/hg/v4l-dvb > mercurial repository for my two cards, a Hauppauge hvr4000 and > TechnoTrend 3200 > > I have one dish with two lnb heads. > > I can, with the hvr4000, scan, lock and stream transponders of both > astra19.2e and hotbird13.0e > > I can, with the tt3200, scan, lock and stream descrambled transponders > of astra19.2e (using a powercam 2.0.3) > > I can, with the tt3200, scan transponders of hotbird13.0e > > I can't, with the tt3200, lock transponders of hotbird13.0e > maybe it's comming from the lnb2p1 driver. The TechniSat SkyStar HD and Azurewave AD SP400 CI (VP-1041) have the same driver. Does someone with a TechniSat SkyStar HD or Azurewave AD SP400 CI (VP-1041) and a dual lnb head manage to lock on the second head ? -- pierre > As a test, I'm running this few commands: > > $> cat hotbird # my transpondeur list > S 12597000 V 2750 3/4 > > $> scan -vvv -a 0 -s 1 hotbird # scanning the transponder > scanning hotbird > > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > > initial transponder 12597000 V 2750 3 > tune to: 12597:v:1:27500 > > DiSEqC: switch pos 1, 13V, hiband (index 6) > > DiSEqC: e0 10 38 f5 00 00 > > DVB-S IF freq is 1997000 > tuning status == 0x1e > > parse_section:1172: pid 0x10 tid 0x40 table_id_ext 0x013e, 0/0 (version > 2) > NIT (actual TS) > > Network Name 'Globecast' > > parse_nit:869: transport_stream_id 0x24b8 > > parse_satellite_delivery_system_descriptor:444: 0x13e/0x24b8 > 12596:v:1:27500 > is_same_transponder:211: f1 = 12597000 is same TP as f2 = 12596560 > > parse_section:1172: pid 0x00 tid 0x00 table_id_ext 0x24b8, 0/0 (version > 8) > PAT > > parse_section:1172: pid 0x41e tid 0x02 table_id_ext 0x2026, 0/0 (version > 1) > PMT 0x041e for service 0x2026 > > AUDIO : PID 0x0854 > > parse_pmt:833: 0x24b8 0x2026: (null) -- (null), pmt_pid 0x041e, vpid > 0x, apid 0x0854 () > parse_section:1172: pid 0x419 tid 0x02 table_id_ext 0x2021, 0/0 (version > 1) > PMT 0x0419 for service 0x2021 > > AUDIO : PID 0x084a > > parse_pmt:833: 0x24b8 0x2021: (null) -- (null), pmt_pid 0x0419, vpid > 0x, apid 0x084a () > parse_section:1172: pid 0x416 tid 0x02 table_id_ext 0x201e, 0/0 (version > 1) > PMT 0x0416 for service 0x201e > > AUDIO : PID 0x0843 > > parse_pmt:833: 0x24b8 0x201e: (null) -- (null), pmt_pid 0x0416, vpid > 0x, apid 0x0843 () > parse_section:1172: pid 0x413 tid 0x02 table_id_ext 0x201b, 0/0 (version > 3) > PMT 0x0413 for service 0x201b > > AUDIO : PID 0x087d > > parse_pmt:833: 0x24b8 0x201b: (null) -- (null), pmt_pid 0x0413, vpid > 0x, apid 0x087d () > parse_section:1172: pid 0x412 tid 0x02 table_id_ext 0x201a, 0/0 (version > 1) > PMT 0x0412 for service 0x201a > > AUDIO : PID 0x083b > > parse_pmt:833: 0x24b8 0x201a: (null) -- (null), pmt_pid 0x0412, vpid > 0x, apid 0x083b () > parse_section:1172: pid 0x411 tid 0x02 table_id_ext 0x2019, 0/0 (version > 1) > PMT 0x0411 for service 0x2019 > > AUDIO : PID 0x0839 > > parse_pmt:833: 0x24b8 0x2019: (null) -- (null), pmt_pid 0x0411, vpid > 0x, apid 0x0839 () > parse_section:1172: pid 0x410 tid 0x02 table_id_ext 0x2018, 0/0 (version > 1) > PMT 0x0410 for service 0x2018 > > AUDIO : PID 0x0837 > > parse_pmt:833: 0x24b8 0x2018: (null) -- (null), pmt_pid 0x0410, vpid > 0x, apid 0x0837 () > parse_section:1172: pid 0x40f tid 0x02 table_id_ext 0x2017, 0/0 (version > 1) > PMT 0x040f for service 0x2017 > > AUDIO : PID 0x0835 > > parse_pmt:833: 0x24b8 0x2017: (null) -- (null), pmt_pid 0x040f, vpid > 0x, apid 0x0835 () > parse_section:1172: pid 0x407 tid 0x02 table_id_ext 0x2010, 0/0 (version > 1) > PMT 0x0407 for service 0x2010 > > AUDIO : PID 0x006c > > VIDEO : PID 0x00a7 > > parse_pmt:833: 0x24b8 0x2010: (null) -- (null), pmt_pid 0x0407, vpid > 0x00a7, apid 0x006c () > parse_section:1172: pid 0x20 tid 0x02 table_id_ext 0x200d, 0/0 (version > 1) > PMT 0x0020 for service 0x200d > > AUDIO : PID 0x005d > > parse_pmt:833: 0x24b8 0x200d: (null) -- (null), pmt_pid 0x0020, vpid > 0x, apid 0x005d () > parse_section:1172: pid 0x403 tid 0x02 table_id_ext 0x200c, 0/0 (version > 4) > PMT 0x0403 for service 0x200c > > TELETEXT : PID 0x0029 > > AUDIO : PID 0x005c > > VIDEO : PID 0x00a3 > > parse_pmt:833: 0x24b8 0x200c: (null) -- (null), pmt_pid 0x0403, vpid > 0x00a3, apid 0x005c () > parse_section:1172: pid 0x402 tid 0x02 table_id_ext 0x200b, 0/0 (version > 1) > PMT 0x0402 for service 0x200b > > parse_pmt:833: 0x24b8 0x200b: (null) -- (null), pmt_pid 0x0402, vpid > 0x, apid 0x () > parse_section:1172: pid 0x401 tid 0x02 table_id_ext 0x200a, 0/0 (version > 1) > PMT 0x0401 for service 0x200a > > AUDIO : PID 0x0054 > > VIDEO : PID 0x00a1 > > parse_pmt:833: 0x24b8 0x200a: (null) -- (null), pmt_pid 0x0401, vpid > 0x00a1, apid 0x0054 () > parse_
[PATCH][RESEND 2] Added support for AVerMedia Cardbus Hybrid remote control
Hi,
please have a look at the attached patch.
Signed-off-by: Oldřich Jedlička
Thanks,
Oldřich.
# HG changeset patch
# User OldÅich JedliÄka
# Date 1232648889 -3600
# Node ID 2b8e5fc5b41f12950de265a4459dbdeee03f1776
# Parent 66e0b01971de89076fcc9a7ef624b35d5451cbe4
Added support for AVerMedia Cardbus Hybrid remote control
From: OldÅich JedliÄka
Added support for I2C device at address 0x40 and subaddress 0x0d/0x0b
that provides remote control key reading support for AVerMedia Cardbus
Hybrid card, possibly for other AVerMedia Cardbus cards.
The I2C address 0x40 doesn't like the SAA7134's 0xfd quirk, so it was
disabled.
Priority: normal
Signed-off-by: OldÅich JedliÄka
diff -r 66e0b01971de -r 2b8e5fc5b41f linux/drivers/media/common/ir-keymaps.c
--- a/linux/drivers/media/common/ir-keymaps.c Thu Jan 22 19:27:07 2009 +0100
+++ b/linux/drivers/media/common/ir-keymaps.c Thu Jan 22 19:28:09 2009 +0100
@@ -154,6 +154,65 @@
};
EXPORT_SYMBOL_GPL(ir_codes_avermedia_m135a);
+/* Oldrich Jedlicka */
+IR_KEYTAB_TYPE ir_codes_avermedia_cardbus[IR_KEYTAB_SIZE] = {
+ [ 0x00 ] = KEY_POWER,
+ [ 0x01 ] = KEY_TUNER, /* TV/FM */
+ [ 0x03 ] = KEY_TEXT, /* Teletext */
+ [ 0x04 ] = KEY_EPG,
+ [ 0x05 ] = KEY_1,
+ [ 0x06 ] = KEY_2,
+ [ 0x07 ] = KEY_3,
+ [ 0x08 ] = KEY_AUDIO,
+ [ 0x09 ] = KEY_4,
+ [ 0x0a ] = KEY_5,
+ [ 0x0b ] = KEY_6,
+ [ 0x0c ] = KEY_ZOOM, /* Full screen */
+ [ 0x0d ] = KEY_7,
+ [ 0x0e ] = KEY_8,
+ [ 0x0f ] = KEY_9,
+ [ 0x10 ] = KEY_PAGEUP, /* 16-CH PREV */
+ [ 0x11 ] = KEY_0,
+ [ 0x12 ] = KEY_INFO,
+ [ 0x13 ] = KEY_AGAIN, /* CH RTN - channel return */
+ [ 0x14 ] = KEY_MUTE,
+ [ 0x15 ] = KEY_EDIT, /* Autoscan */
+ [ 0x17 ] = KEY_SAVE, /* Screenshot */
+ [ 0x18 ] = KEY_PLAYPAUSE,
+ [ 0x19 ] = KEY_RECORD,
+ [ 0x1a ] = KEY_PLAY,
+ [ 0x1b ] = KEY_STOP,
+ [ 0x1c ] = KEY_FASTFORWARD,
+ [ 0x1d ] = KEY_REWIND,
+ [ 0x1e ] = KEY_VOLUMEDOWN,
+ [ 0x1f ] = KEY_VOLUMEUP,
+ [ 0x22 ] = KEY_SLEEP, /* Sleep */
+ [ 0x23 ] = KEY_ZOOM, /* Aspect */
+ [ 0x26 ] = KEY_SCREEN, /* Pos */
+ [ 0x27 ] = KEY_ANGLE, /* Size */
+ [ 0x28 ] = KEY_SELECT, /* Select */
+ [ 0x29 ] = KEY_BLUE, /* Blue/Picture */
+ [ 0x2a ] = KEY_BACKSPACE, /* Back */
+ [ 0x2b ] = KEY_MEDIA, /* PIP (Picture-in-picture) */
+ [ 0x2c ] = KEY_DOWN,
+ [ 0x2e ] = KEY_DOT,
+ [ 0x2f ] = KEY_TV, /* Live TV */
+ [ 0x32 ] = KEY_LEFT,
+ [ 0x33 ] = KEY_CLEAR, /* Clear */
+ [ 0x35 ] = KEY_RED, /* Red/TV */
+ [ 0x36 ] = KEY_UP,
+ [ 0x37 ] = KEY_HOME, /* Home */
+ [ 0x39 ] = KEY_GREEN, /* Green/Video */
+ [ 0x3d ] = KEY_YELLOW, /* Yellow/Music */
+ [ 0x3e ] = KEY_OK, /* Ok */
+ [ 0x3f ] = KEY_RIGHT,
+ [ 0x40 ] = KEY_NEXT, /* Next */
+ [ 0x41 ] = KEY_PREVIOUS, /* Previous */
+ [ 0x42 ] = KEY_CHANNELDOWN, /* Channel down */
+ [ 0x43 ] = KEY_CHANNELUP /* Channel up */
+};
+EXPORT_SYMBOL_GPL(ir_codes_avermedia_cardbus);
+
/* Attila Kondoros */
IR_KEYTAB_TYPE ir_codes_apac_viewcomp[IR_KEYTAB_SIZE] = {
diff -r 66e0b01971de -r 2b8e5fc5b41f linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.c Thu Jan 22 19:27:07 2009 +0100
+++ b/linux/drivers/media/video/ir-kbd-i2c.c Thu Jan 22 19:28:09 2009 +0100
@@ -16,6 +16,8 @@
* Henry Wong
* Mark Schultz
* Brian Rogers
+ * modified for AVerMedia Cardbus by
+ * Oldrich Jedlicka
*
* 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
@@ -217,6 +219,46 @@
return 1;
}
+static int get_key_avermedia_cardbus(struct IR_i2c *ir,
+ u32 *ir_key, u32 *ir_raw)
+{
+ unsigned char subaddr, key, keygroup;
+ struct i2c_msg msg[] = {{.addr=ir->c.addr, .flags=0, .buf=&subaddr,
+.len = 1},
+{.addr=ir->c.addr, .flags=I2C_M_RD, .buf=&key,
+.len = 1}};
+ subaddr = 0x0d;
+ if (2 != i2c_transfer(ir->c.adapter, msg, 2)) {
+ dprintk(1, "read error\n");
+ return -EIO;
+ }
+
+ if (key == 0xff)
+ return 0;
+
+ subaddr = 0x0b;
+ msg[1].buf = &keygroup;
+ if (2 != i2c_transfer(ir->c.adapter, msg, 2)) {
+ dprintk(1, "read error\n");
+ return -EIO;
+ }
+
+ if (keygroup == 0xff)
+ return 0;
+
+ dprintk(1, "read key 0x%02x/0x%02x\n", key, keygroup);
+ if (keygroup < 2 || keygroup > 3) {
+ /* Only a warning */
+ dprintk(1, "warning: invalid key group 0x%02x for key 0x%02x\n",
+keygroup, key);
+ }
+ key |= (keygroup & 1) << 6;
+
+ *ir_key = key;
+ *ir_raw = key;
+ return 1;
+}
+
/* --- */
static void ir_key_poll(struct IR_i2c *ir)
@@ -369,6 +411,12 @@
ir_type = IR_TYPE_OTHER;
}
break;
+ case 0x40:
+ name= "AVerMedia Cardbus remote";
+ ir->get_key = get_key_avermedia_cardbus;
+ ir_type = IR_TYPE_OTHER;
+ ir_codes= ir_codes_avermedia_cardbus;
+ break;
default:
/* shouldn't happen */
printk(DEVNAME ": Huh? unknown i2c address (0x%02x)?\n", addr);
@@ -537,6 +585,22 @@
ir_attach(adap, msg.addr, 0, 0);
}
+ /* Special case for AVer
Re: [PATCH] DAB: fix typo
On Sun, 1 Feb 2009, Németh Márton wrote: > From: Márton Németh > > Fix typo in "DAB adapters" section in Kconfig. > > Signed-off-by: Márton Németh > --- > --- linux-2.6.29-rc3/drivers/media/Kconfig.orig 2008-12-25 > 00:26:37.0 +0100 > +++ linux-2.6.29-rc3/drivers/media/Kconfig2009-02-01 13:30:54.0 > +0100 > @@ -117,7 +117,7 @@ source "drivers/media/dvb/Kconfig" > config DAB > boolean "DAB adapters" > ---help--- > - Allow selecting support for for Digital Audio Broadcasting (DAB) > + Allow selecting support for Digital Audio Broadcasting (DAB) > Receiver adapters. Didn't find this in today's linux-next, so I have applied it to trivial tree. Thanks, -- Jiri Kosina SUSE Labs
Re: failure of Cinergy Hybrid T USB XS on amd64
On Wed, Feb 11, 2009 at 10:42 AM, Simon Kenyon wrote: > does anyone know what is going on here? > > i know the device works because i can use it on my eee 900 running gentoo > > however i get a failure to load the driver (hg pull as of yesterday) on two > different linux boxes. they are both running gentoo on an amd64 > > uname -a gives: > > Linux newyork 2.6.27-gentoo-r8 #1 SMP PREEMPT Wed Feb 11 00:10:13 GMT 2009 > x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux Hi, I currently have the same issue while trying to make my Dazzle TV Hybrid (USB ID eb1a:2881, looks like the exact same hardware as the Pinnacle Hybrid Pro) work with the v4l-dvb tree from linuxtv.org on my 64-bit systems (Kubuntu 8.10, Linux 2.6.27, AMD Sempron 64 and Intel Core 2 Duo). My USB device seems very similar to yours : em288x, tvp5150, xc3028 and zl10353 chips. I've added some code to the em28xx driver to provide support for my device, but for now I'm stuck with the "zl10353_read_register: readreg error (reg=127, ret==-19)" error message... Note that the device works with the em28xx-new driver from mcentral.de. > and this is the output from the driver load: > > usb 2-1: new high speed USB device using ehci_hcd and address 4 > usb 2-1: configuration #1 chosen from 1 choice > em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS @ 480 > Mbps (0ccd:0042, interface 0, class 0) > em28xx #0: Identified as Terratec Hybrid XS (card=11) > em28xx #0: chip ID is em2882/em2883 > tvp5150' 2-005c: chip found @ 0xb8 (em28xx #0) > tuner' 2-0061: chip found @ 0xc2 (em28xx #0) > em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 42 00 50 12 5c 03 6a 32 9c 34 > em28xx #0: i2c eeprom 10: 00 00 06 57 46 07 00 00 00 00 00 00 00 00 00 00 > em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 00 00 00 > em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 > em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 32 03 43 00 69 00 > em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 48 00 79 00 > em28xx #0: i2c eeprom 80: 62 00 72 00 69 00 64 00 20 00 54 00 20 00 55 00 > em28xx #0: i2c eeprom 90: 53 00 42 00 20 00 58 00 53 00 00 00 34 03 54 00 > em28xx #0: i2c eeprom a0: 65 00 72 00 72 00 61 00 54 00 65 00 63 00 20 00 > em28xx #0: i2c eeprom b0: 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 > em28xx #0: i2c eeprom c0: 69 00 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 > em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x41d0bf96 > em28xx #0: EEPROM info: > em28xx #0: AC97 audio (5 sample rates) > em28xx #0: 500mA max power > em28xx #0: Table at 0x06, strings=0x326a, 0x349c, 0x > xc2028 2-0061: creating new instance > xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner > firmware: requesting xc3028-v27.fw > xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 > firmware, ver 2.7 > xc2028 2-0061: Loading firmware for type=BASE (1), id . > xc2028 2-0061: Loading firmware for type=(0), id b700. > SCODE (2000), id b700: > xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id > 8000. > em28xx #0: Config register raw data: 0x50 > em28xx #0: AC97 vendor ID = 0x83847652 > em28xx #0: AC97 features = 0x6a90 > em28xx #0: Sigmatel audio processor detected(stac 9752) > tvp5150' 2-005c: tvp5150am1 detected. > em28xx #0: v4l2 driver version 0.1.1 > em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi1 > zl10353_read_register: readreg error (reg=127, ret==-19) > em28xx #0/2: dvb frontend not attached. Can't attach xc3028 > > -- > 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
PULL request
Hi Mauro, I pushed several changesets to my tree and would like to ask you to pull them. - [PATCH] Add support for Winfast Dongle Hybrid - [PATCH] Emtec S810 (1164:2edc) support - [PATCH] Add Elgato EyeTV Diversity to dibcom driver - Wipe out an obsolete documentation about Flexcop refactoring - documentation fix for /Documentation/dvb/technisat.txt The most important one is - [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards which fixes a problem with the recently added 2.8 revsion of the Technisat SkyStar2. If possible we should get that into 2.6.29 in order to have a proper support for this card. thanks, Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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
failure of Cinergy Hybrid T USB XS on amd64
does anyone know what is going on here? i know the device works because i can use it on my eee 900 running gentoo however i get a failure to load the driver (hg pull as of yesterday) on two different linux boxes. they are both running gentoo on an amd64 uname -a gives: Linux newyork 2.6.27-gentoo-r8 #1 SMP PREEMPT Wed Feb 11 00:10:13 GMT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux and this is the output from the driver load: usb 2-1: new high speed USB device using ehci_hcd and address 4 usb 2-1: configuration #1 chosen from 1 choice em28xx: New device TerraTec Electronic GmbH Cinergy Hybrid T USB XS @ 480 Mbps (0ccd:0042, interface 0, class 0) em28xx #0: Identified as Terratec Hybrid XS (card=11) em28xx #0: chip ID is em2882/em2883 tvp5150' 2-005c: chip found @ 0xb8 (em28xx #0) tuner' 2-0061: chip found @ 0xc2 (em28xx #0) em28xx #0: i2c eeprom 00: 1a eb 67 95 cd 0c 42 00 50 12 5c 03 6a 32 9c 34 em28xx #0: i2c eeprom 10: 00 00 06 57 46 07 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 31 00 b8 00 14 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01 00 00 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 32 03 43 00 69 00 em28xx #0: i2c eeprom 70: 6e 00 65 00 72 00 67 00 79 00 20 00 48 00 79 00 em28xx #0: i2c eeprom 80: 62 00 72 00 69 00 64 00 20 00 54 00 20 00 55 00 em28xx #0: i2c eeprom 90: 53 00 42 00 20 00 58 00 53 00 00 00 34 03 54 00 em28xx #0: i2c eeprom a0: 65 00 72 00 72 00 61 00 54 00 65 00 63 00 20 00 em28xx #0: i2c eeprom b0: 45 00 6c 00 65 00 63 00 74 00 72 00 6f 00 6e 00 em28xx #0: i2c eeprom c0: 69 00 63 00 20 00 47 00 6d 00 62 00 48 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x41d0bf96 em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: 500mA max power em28xx #0: Table at 0x06, strings=0x326a, 0x349c, 0x xc2028 2-0061: creating new instance xc2028 2-0061: type set to XCeive xc2028/xc3028 tuner firmware: requesting xc3028-v27.fw xc2028 2-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 2-0061: Loading firmware for type=BASE (1), id . xc2028 2-0061: Loading firmware for type=(0), id b700. SCODE (2000), id b700: xc2028 2-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. em28xx #0: Config register raw data: 0x50 em28xx #0: AC97 vendor ID = 0x83847652 em28xx #0: AC97 features = 0x6a90 em28xx #0: Sigmatel audio processor detected(stac 9752) tvp5150' 2-005c: tvp5150am1 detected. em28xx #0: v4l2 driver version 0.1.1 em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi1 zl10353_read_register: readreg error (reg=127, ret==-19) em28xx #0/2: dvb frontend not attached. Can't attach xc3028 -- 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] V4L/DVB: calibration still successful at 10
With while (i++ < 10) { ... } i can reach 11, so callibration still
succeeds at i == 10.
Signed-off-by: Roel Kluin
---
diff --git a/drivers/media/common/tuners/mt2060.c
b/drivers/media/common/tuners/mt2060.c
index 12206d7..c7abe3d 100644
--- a/drivers/media/common/tuners/mt2060.c
+++ b/drivers/media/common/tuners/mt2060.c
@@ -278,7 +278,7 @@ static void mt2060_calibrate(struct mt2060_priv *priv)
while (i++ < 10 && mt2060_readreg(priv, REG_MISC_STAT, &b) == 0 && (b &
(1 << 6)) == 0)
msleep(20);
- if (i < 10) {
+ if (i <= 10) {
mt2060_readreg(priv, REG_FM_FREQ, &priv->fmfreq); // now find
out, what is fmreq used for :)
dprintk("calibration was successful: %d", (int)priv->fmfreq);
} else
--
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
