PCTV (ex Pinnacle) 74e pico USB stick DVB-T: no frontend registered
Hello, I've run into a roadblock problem with my PCTV 74e pico USB stick for receiving DVB-T. My setup is as follows: the system is a Kubuntu Kaotic Koala 9.10 stock distribution, kept current. The Linux kernel is thus a 2.6.31-18-generic one as distributed by Ubuntu. It contains the stock kernel video4linux and I also installed the non-free firmware package in order to have the dvb-usb-dib0700-1.20.fw firmware at hand. With this setup, the pico was not even properly recognized (USB VID:DID = 2013:0246). Yesterday I pulled the most recent set of v4l-dvb files of the mercury repository using hg clone http://linuxtv.org/hg/v4l-dvb;. For reasons I yet don't understand, this file set does not include the complete patch from http://linuxtv.org/hg/v4l-dvb/rev/87039167057078a29ca91c1bcd3369977d6ca463 While dvb-usb-ids.h does already contain the PCTV vendor ID as well as USB_PID_PINNACLE_PCTV74E device ID, file dib0700_devices.c does not contain the registration. The patch from the patchset mentioned above does register the 74e together with 73e. The problem now is that after compiling everything (by switching off build of most modules in order to avoid kfifo problems) and installing the new modules I hit the roadblock. Inserting the pico and doing dmesg | grep -i dvb yields: [10650.021155] dvb-usb: found a 'Pinnacle PCTV 74e' in cold state, will try to load a firmware [10650.021170] usb 1-4: firmware: requesting dvb-usb-dib0700-1.20.fw [10650.041879] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [10650.840668] dvb-usb: found a 'Pinnacle PCTV 74e' in warm state. [10650.840870] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [10650.841284] DVB: registering new adapter (Pinnacle PCTV 74e) [10650.908062] dvb-usb: no frontend was attached by 'Pinnacle PCTV 74e' [10650.908292] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-4/input/input21 [10650.908429] dvb-usb: schedule remote query interval to 50 msecs. [10650.908441] dvb-usb: Pinnacle PCTV 74e successfully initialized and connected. It seems that the frontend registration did (silently) fail, at least from the perspective of dib0700_devices.c. Has anyone information whether the 74e shares the same frontend with the 73e? With best regards, -- Harald -- 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: PCTV (ex Pinnacle) 74e pico USB stick DVB-T: no frontend registered
Hi Harald, On Sunday 17 January 2010 09:57:03 Harald Albrecht wrote: Hello, I've run into a roadblock problem with my PCTV 74e pico USB stick for receiving DVB-T. My setup is as follows: the system is a Kubuntu Kaotic Koala 9.10 stock distribution, kept current. The Linux kernel is thus a 2.6.31-18-generic one as distributed by Ubuntu. It contains the stock kernel video4linux and I also installed the non-free firmware package in order to have the dvb-usb-dib0700-1.20.fw firmware at hand. With this setup, the pico was not even properly recognized (USB VID:DID = 2013:0246). Yesterday I pulled the most recent set of v4l-dvb files of the mercury repository using hg clone http://linuxtv.org/hg/v4l-dvb;. For reasons I yet don't understand, this file set does not include the complete patch from http://linuxtv.org/hg/v4l-dvb/rev/87039167057078a29ca91c1bcd3369977d6ca463 This one was followed by http://linuxtv.org/hg/v4l-dvb/rev/c0af9bb51052 which removed the association of the 74e to the dib0700-driver. It seems that the frontend registration did (silently) fail, at least from the perspective of dib0700_devices.c. Has anyone information whether the 74e shares the same frontend with the 73e? The 74e is not a dib0700-based device, my assumption at that time was wrong. For the 74e afaik, there is no LinuxTV driver right now. (IIRC it is a Abilis based design) best regards, -- Patrick Boettcher - KernelLabs http://www.kernellabs.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Terratec Cinergy HT Express analog tv, fm and digital radio
Hello. Regarding the Terratec Cinergy HT Express i was wondering if the analog tv, fm radio and digital radio have been supported (the DVBT is supposed to work according to several threads)? Also, for reasons not important to present here, i am using a very old kernel 2.6.22 so please state the minimum kernel version on which the above features are supported. Thank you. Regards. -- 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: I2C transaction questions: irq context and client locking
Hi Andy,
On Sat, 16 Jan 2010 23:59:28 -0500, Andy Walls wrote:
I have a few basic questions related to the cx23885 driver and
processing interrupts from a device connected over an I2C bus.
1. Under what conditions, if any, would it be safe to perform I2C reads
and writes in an irq handler context? The cx23885 i2c implementation
doesn't appear to schedule() or try and grab a mutex, so I'm pretty sure
it doesn't sleep.
If the bus driver itself doesn't sleep, it is safe to perform I2C
transactions from an interrupt handler. If you trust the code in
i2c-core.c:i2c_transfer():
if (in_atomic() || irqs_disabled()) {
ret = rt_mutex_trylock(adap-bus_lock);
if (!ret)
/* I2C activity is ongoing. */
return -EAGAIN;
} else {
rt_mutex_lock(adap-bus_lock);
}
I seem to recall that Andrew Morton expressed some doubts about the
validity of the above code. He claimed that it should be up to the
caller to decide whether a failure to get the bus lock should return
immediately or block. However, so far nobody seemed to be interested in
actually changing this.
2. Is there any built in locking mechanism built in to the I2C subsystem
so a caller can get exclusive access to an I2C client on a bus? I know
there is an adapter mutex to avoid collisions at a transfer level. I
was looking for something that could be used at the transaction or
multi-transaction level.
The short answer is no, there is not. However, when all users properly
declare their I2C devices (struct i2c_client), the address of each
device is marked as busy by i2c-core. This means that you have a kind
of cooperation-based exclusive access grant. It isn't bullet proof
though. Amongst others, i2c-dev can bypass the check, and more
generally any user doing raw I2C transactions won't notice.
Please note that the dvb subsystem has decided to _not_ rely on struct
i2c_client, for historical reasons (the i2c binding model sucked back
then). So you need to have a global view of everything that happens on
the DVB card I2C bus to make sure that no conflict will happen, and if
any mutual exclusion mechanism is required, it is up to you to
implement it.
When you need to issue several transactions and do not wish to get
interrupted, the only way currently is to not release the bus between
them. That is, prepare a bunch of transactions and run them all at once
using i2c_transfer(). Many cases don't fit though, for example
read-modify-write does not. Also, not all chips honor repeated start,
which the chips which do, may not support it in all cases.
I agree that there is probably some room for improvement in this area.
The cx25840 driver has gems like this in it:
u8 cx25840_read(struct i2c_client * client, u16 addr)
{
u8 buffer[2];
buffer[0] = addr 8;
buffer[1] = addr 0xff;
if (i2c_master_send(client, buffer, 2) 2)
return 0;
if (i2c_master_recv(client, buffer, 1) 1)
return 0;
return buffer[0];
}
So a read transaction is two separate transfers. I see some problems
with this function:
I do as well ;)
a. when called from a process or workqueue context, the read transaction
can be corrupted if an interrupt handler came in and accessed the i2c
client.
b two near simultaneous calls from a workqueue or process context can
get interleaved and corrupt the transactions
c. if this were called from an irqs_disabled() context and the bus
adapter mutex can't be obtained, the EAGAIN is thrown away. :(
(Is it even safe to do mutex_trylock() from an irq context?)
This is all correct. Unless the underlying I2C controller is unable to
issue combined transactions, the above should be replaced by a single
call to i2c_transfer(). That way, you'd be certain that it never gets
interrupted. This solves items a and b above. It would also increase
performance a bit (repeated start takes less time than stop + start).
If you can't for technical (hardware) reasons, then the easiest
workaround is to have your own mutex or spinlock protecting access to
the chip (that is, in cx25840_write(), i2c_master_send(),
cx25840_read() and cx25840_read4().)
I suppose I'll just have to disable the interuupt from the device and
push everything off to a workqueue when an interrupt comes in. Then
once the workhandler is done accessing the device, it can re-enable the
interrupt. That still leaves me with possible collisions from multipe
process or workqueue contexts.
I suspect you'll need a workqueue either way. If interrupts come and
you can't afford losing them, then the behavior of i2c_transfer() won't
please you. Either it sleeps, or it returns -EAGAIN, which you'll have
to handle. If you retry forever without sleeping, it might take long
before you can proceed, and performance will
Re: Kworld 315U and SAA7113?
Franklin Meng wrote: Devin, I'm actually not really concerned about it's interaction with a demod. I'm more worried about other products that have saa711[345] that use a bridge other than em28xx. The introduction of power management could always expose bugs in those bridges (I had this problem in several different cases where I had to fix problems in other drivers because of the introduction of power management). I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. This happens on several designs. In general, the gpio sequence will turn off either the analog or the digital part of the device, in order to save power and to avoid overheating the device. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Don't do that. You may burn your device. Either way it looks like I will have to reinitialize the device after switching between interfaces. The em28xx driver calls em28xx_set_mode(dev, EM28XX_ANALOG_MODE); when the device is opened in analog mode. It seems that we'll need some code there to also call the analog demod to re-initiate the device, after sending the gpio commands. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. In suspend state, it will be cooler than when in normal state. It is better to keep the suspend state to increase the lifetime of the device. Thanks, Franklin Meng -- 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
[PATCH] Compro S350 GPIO change
Hi, This patch enables LNB power on newer revision d1 Compro S350 and S300 DVB-S cards. While I don't have these cards to test with I'm confident that this works. See http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/7471 and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/14296 and new windows driver as reference. Signed-off-by: JD Louw jd.l...@mweb.co.za diff -r 59e746a1c5d1 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Dec 30 09:10:33 2009 -0200 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 17 14:51:07 2010 +0200 @@ -7037,8 +7037,8 @@ int saa7134_board_init1(struct saa7134_d break; case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; - saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); - saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); + saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000); + saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000); break; } return 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
[PATCH 1/2, RFC] gspca: add input support for interrupt endpoints
From: Márton Németh nm...@freemail.hu
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 13:47:44 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
+ *
* 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
@@ -41,6 +44,9 @@
#include gspca.h
+#include linux/input.h
+#include linux/usb/input.h
+
/* global values */
#define DEF_NURBS 3/* default number of URBs */
#if DEF_NURBS MAX_NURBS
@@ -112,6 +118,167 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb-context;
+ int ret;
+
+ if (urb-status == 0) {
+ if (gspca_dev-sd_desc-int_pkt_scan(gspca_dev,
+ urb-transfer_buffer, urb-actual_length) 0) {
+ PDEBUG(D_ERR, Unknown packet received);
+ }
+
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret 0)
+ PDEBUG(D_ERR, Resubmit URB failed with error %i, ret);
+ }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev-input_dev = NULL;
+ if (dev-sd_desc-int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev-dev, dev-phys, sizeof(dev-phys));
+ strlcat(dev-phys, /input0, sizeof(dev-phys));
+
+ input_dev-name = dev-sd_desc-name;
+ input_dev-phys = dev-phys;
+
+ usb_to_input_id(dev-dev, input_dev-id);
+
+ input_dev-evbit[0] = BIT_MASK(EV_KEY);
+ input_dev-keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev-dev.parent = dev-dev-dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, Input device registration failed
+ with error %i, err);
+ input_dev-dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev-input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep-wMaxPacketSize;
+ interval = ep-bInterval;
+ PDEBUG(D_PROBE, found int in endpoint: 0x%x,
+ buffer_len=%u, interval=%u,
+ ep-bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev-dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev, ep-wMaxPacketSize,
+ GFP_KERNEL, urb-transfer_dma);
+ if (!buffer) {
+ ret = -ENOMEM;
+ goto error_buffer;
+ }
+ usb_fill_int_urb(urb, dev,
+ usb_rcvintpipe(dev, ep-bEndpointAddress),
+ buffer, buffer_len,
+ int_irq, (void *)gspca_dev, interval);
+ gspca_dev-int_urb = urb;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret 0) {
+ PDEBUG(D_ERR, submit URB failed with error %i, ret);
+ goto error_submit;
+ }
+ return ret;
+
+error_submit:
+ usb_buffer_free(dev,
+ urb-transfer_buffer_length,
+ urb-transfer_buffer,
+ urb-transfer_dma);
+error_buffer:
+ usb_free_urb(urb);
+error:
+ return ret;
+}
+
+static int gspca_input_create_urb(struct gspca_dev *gspca_dev)
+{
+ int ret = -EINVAL;
+ struct usb_interface *intf;
+ struct usb_host_interface *intf_desc;
+ struct usb_endpoint_descriptor *ep;
+ int i;
+
+ if (gspca_dev-sd_desc-int_pkt_scan) {
[PATCH 2/2, RFC] gspca pac7302: add support for camera button
From: Márton Németh nm...@freemail.hu
Add support for snapshot button found on Labtec Webcam 2200.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 17 13:47:50 2010 +0100
@@ -5,6 +5,8 @@
* V4L2 by Jean-Francois Moine http://moinejf.free.fr
*
* Separated from Pixart PAC7311 library by M�rton N�meth nm...@freemail.hu
+ * Camera button input handling by Márton Németh nm...@freemail.hu
+ * Copyright (C) 2009-2010 Márton Németh nm...@freemail.hu
*
* 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
@@ -68,6 +70,7 @@
#define MODULE_NAME pac7302
+#include linux/input.h
#include media/v4l2-chip-ident.h
#include gspca.h
@@ -1164,6 +1167,37 @@
}
#endif
+#ifdef CONFIG_INPUT
+static int sd_int_pkt_scan(struct gspca_dev *gspca_dev,
+ u8 *data, /* interrupt packet data */
+ int len)/* interrput packet length */
+{
+ int ret = -EINVAL;
+ u8 data0, data1;
+
+ if (len == 2) {
+ data0 = data[0];
+ data1 = data[1];
+ if ((data0 == 0x00 data1 == 0x11) ||
+ (data0 == 0x22 data1 == 0x33) ||
+ (data0 == 0x44 data1 == 0x55) ||
+ (data0 == 0x66 data1 == 0x77) ||
+ (data0 == 0x88 data1 == 0x99) ||
+ (data0 == 0xaa data1 == 0xbb) ||
+ (data0 == 0xcc data1 == 0xdd) ||
+ (data0 == 0xee data1 == 0xff)) {
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 1);
+ input_sync(gspca_dev-input_dev);
+ input_report_key(gspca_dev-input_dev, KEY_CAMERA, 0);
+ input_sync(gspca_dev-input_dev);
+ ret = 0;
+ }
+ }
+
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static const struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1180,6 +1214,9 @@
.set_register = sd_dbg_s_register,
.get_chip_ident = sd_chip_ident,
#endif
+#ifdef CONFIG_INPUT
+ .int_pkt_scan = sd_int_pkt_scan,
+#endif
};
/* -- module initialisation -- */
--
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
Hauppauge Win TV HVR-1300: streaming and grabbing fail after a while, changing resolution renders card inoperable
Hi! I have a Hauppauge HVR-1300 which I currently intend to use for capturing analog cable tv, because of the hardware mpeg encoder. There are three problems, which might or might not be related: 1) mpeg stream from hardware encoder breaks off or is corrupted (I can't tell which) after a while 2) screengrabber image gets corrupted after a while 3) changing resolutions causes mpeg encoder stream to become completely inoperable I've made sure to reproduce all problems with an untainted 2.6.32 kernel (package linux-image-2.6.32-trunk-amd64 version 2.6.32-5 from ubuntu). 1) mpeg stream from hardware encoder breaking: After setting a channel with ivtv-tune -d /dev/video1 -t europe-west -c E6 I can play the mpeg stream e.g. with mplayer -nofs -vo x11 /dev/video1 -cache 8192 but after a while (ranging from a few seconds to several minutes (up to five, I think)) the video stream seems to break off. mplayer shows a freezed frame, there's no sound. Sometimes mplayer will terminate with end of file. The same happens when I do cat /dev/video1 test.mpg and play test.mpg with mplayer, however the test.mpg file still grows, so there's some output from the device, mplayer apparently just isn't able to play it. I still get end of file with this file, even though mplayer displays it's 7 minutes or longer, just the first minute will be played. I've unloaded the modules and reloaded them with modprobe cx2341x debug=1 modprobe cx88_blackbird debug=1 video_debug=1 mpegbufs=32 in order to get some debug output in dmesg. dmesg output was pastebinned at http://pastebin.com/f60ad5dcc since it's too long for this list. (In case you're curious about the backtrace in the beginning, I uploaded the start of syslog at http://pastebin.com/f3bac25d7 I'd also like to know if it might indicate problems.) 2) corrupted image from screengrabber: There are also problems with the framegrabber on /dev/video0. When I watch analog tv directly (with mythtv or tvtime), after a while (again a few seconds up to a few minutes), the picture shrinks to an area in the upper right corner. In the lower parts there are sometimes moving artefacts. If I run a tail -f on syslog I see nothing, but this time I didn't give any debug options to the modules (also I was using an older kernel, tainted by the fglrx driver. If you want, I can reproduce this with the untainted 2.6.32 again.) I've uploaded a screenshot from tvtime to http://dudelab.org/~taupan/tvtime-output-22:45:53.jpg xawtv display looks very weird... as if every eighth line was shifted by about a 16th of its width or so. Example image at http://dudelab.org/~taupan/snap-viva-20100117-142327-1.jpeg (I used roughly the same xawtv configuration with an ancient hauppauge card from 1997 which I used successfully until recently.) 3) broken resolution switching: When I switch resolutions in mythtv recording profile, but also via e.g. v4l2-ctl -d /dev/video1 --set-fmt-video=width=720,height=568 I seem to totally break the encoder. There's no stream any more, ~ cat /dev/video1 cat: /dev/video1: Input/output error And switching the resolution back doesn't help. Unloading the modules doesn't help either, I have to reboot the box. dmesg output pastebinned at http://pastebin.com/f4e27757a Tests were done with a 2.6.32 kernel from ubuntu. Please ask if there's any information you can't easily infer from this mail or the attached logs. Kind regards Friedel -- Friedrich Delgado Friedrichs frie...@nomaden.org TauPan on Ircnet and Freenode ;) -- 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
[GIT PATCHES for 2.6.33] V4L/DVB fixes
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For the following fixes: - cx25821: fix double unlock in medusa_video_init() - dib8000: fix compilation if !DVB_DIB8000 - feature-removal-schedule: Add v4l1 drivers obsoleted by gspca sub drivers - gspca core: Set the current frame pointer when first qbuf. - gspca subdriver fixes: - 5k4aa: Add vflip quirk for the Amilo Xi 2428 - ov534: Fix a compilation warning - sn9c20x: Fix test of unsigned - stv06xx-vv6410: Ensure register STV_SCAN_RATE is zero - sunplus: Fix bridge exchanges - vc032x: Fix a possible crash with the vc0321 bridge. - ir-keytable: use the right header - lgdt3305: make one-bit bitfields unsigned - MAINTAINERS: Andy Walls is the new ivtv maintainer and the ivtv list is moderated - mx1_camera: don't check platform_get_irq's return value against zero - rj54n1cb0c: remove compiler warning - saa7134: DVB-T regression fix - sh_mobile_ceu: don't check platform_get_irq's return value against zero - tda8290: add autodetection support for TDA8295c2 and fix FM radio - uvcvideo: fix alt setting for isoc mode, controls backlists and an oops due to a race condition Cheers, Mauro. --- Documentation/feature-removal-schedule.txt | 49 MAINTAINERS|7 +-- drivers/media/IR/ir-keytable.c |2 +- drivers/media/common/tuners/tda8290.c | 12 +++-- drivers/media/dvb/frontends/dib8000.h |2 +- drivers/media/dvb/frontends/lgdt3305.h |6 +- drivers/media/video/gspca/gspca.c |2 + drivers/media/video/gspca/m5602/m5602_s5k4aa.c |6 ++ drivers/media/video/gspca/ov534.c |2 +- drivers/media/video/gspca/sn9c20x.c|2 +- drivers/media/video/gspca/stv06xx/stv06xx_vv6410.h |1 + drivers/media/video/gspca/sunplus.c| 26 +- drivers/media/video/gspca/vc032x.c |4 ++ drivers/media/video/mx1_camera.c |2 +- drivers/media/video/rj54n1cb0c.c |2 +- drivers/media/video/saa7134/saa7134-core.c | 13 - drivers/media/video/saa7134/saa7134-ts.c | 13 + drivers/media/video/sh_mobile_ceu_camera.c |2 +- drivers/media/video/uvc/uvc_ctrl.c |2 +- drivers/media/video/uvc/uvc_queue.c| 13 -- drivers/media/video/uvc/uvc_video.c| 45 +++--- drivers/media/video/uvc/uvcvideo.h |5 +- drivers/staging/cx25821/cx25821-medusa-video.c |4 +- 23 files changed, 151 insertions(+), 71 deletions(-) Dan Carpenter (1): V4L/DVB (13955): cx25821: fix double unlock in medusa_video_init() Dmitri Belimov (1): V4L/DVB (13966): DVB-T regression fix for saa7134 cards Erik Andren (1): V4L/DVB (13880): gspca - m5602-s5k4aa: Add vflip quirk for the Amilo Xi 2428 Erik Andrén (1): V4L/DVB (13882): gspca - stv06xx-vv6410: Ensure register STV_SCAN_RATE is zero Hans Verkuil (1): MAINTAINERS: Andy Walls is the new ivtv maintainer Hans de Goede (1): feature-removal-schedule: Add v4l1 drivers obsoleted by gspca sub drivers Jean-Francois Moine (4): V4L/DVB (13816): gspca - main: Set the current frame pointer when first qbuf. V4L/DVB (13622): gspca - ov534: Fix a compilation warning. V4L/DVB (13875): gspca - vc032x: Fix a possible crash with the vc0321 bridge. V4L/DVB (13900): gspca - sunplus: Fix bridge exchanges. Jiri Slaby (1): MAINTAINERS: ivtv-devel is moderated Laurent Pinchart (3): V4L/DVB (13826): uvcvideo: Fix controls blacklisting V4L/DVB (13829): uvcvideo: Fix alternate setting selection in isochronous mode V4L/DVB (13831): uvcvideo: Fix oops caused by a race condition in buffer dequeuing Mauro Carvalho Chehab (2): V4L/DVB (13834): dib8000: fix compilation if !DVB_DIB8000 V4L/DVB (13858): ir-keytable: use the right header Michael Krufky (2): V4L/DVB (13887): tda8290: add autodetection support for TDA8295c2 V4L/DVB (13934): tda8290: Fix FM radio easy programming standard selection for TDA8295 Márton Németh (1): V4L/DVB (13941): rj54n1cb0c: remove compiler warning Nemeth Marton (1): V4L/DVB (13820): lgdt3305: make one-bit bitfields unsigned Roel Kluin (1): V4L/DVB (13868): gspca - sn9c20x: Fix test of unsigned. Uwe Kleine-König (2): V4L/DVB mx1_camera: don't check platform_get_irq's return value against zero V4L/DVB sh_mobile_ceu: don't check platform_get_irq's return value against zero --- V4L/DVB development is hosted at http://linuxtv.org -- To unsubscribe from this list: send the line unsubscribe
[GIT PATCHES for 2.6.33] DVB Mantis driver
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git mantis For the DVB mantis driver. This is a new driver that add support for the DVB devices based on ST mantis chips. This design is becoming very popular and the driver were already out of the kernel tree for some time. As this driver doesn't touch on the existing code, were already confirmed to work by several people, and is being on linux-next since December, I'm hoping that you'll accept its late submission for 2.6.33. Cheers, Mauro. --- drivers/media/dvb/Kconfig |4 + drivers/media/dvb/Makefile | 14 +- drivers/media/dvb/frontends/Kconfig| 19 + drivers/media/dvb/frontends/Makefile |2 + drivers/media/dvb/frontends/mb86a16.c | 1878 drivers/media/dvb/frontends/mb86a16.h | 52 + drivers/media/dvb/frontends/mb86a16_priv.h | 151 +++ drivers/media/dvb/frontends/tda10021.c |4 + drivers/media/dvb/frontends/tda665x.c | 257 drivers/media/dvb/frontends/tda665x.h | 52 + drivers/media/dvb/mantis/Kconfig | 32 + drivers/media/dvb/mantis/Makefile | 28 + drivers/media/dvb/mantis/hopper_cards.c| 275 drivers/media/dvb/mantis/hopper_vp3028.c | 88 ++ drivers/media/dvb/mantis/hopper_vp3028.h | 30 + drivers/media/dvb/mantis/mantis_ca.c | 207 +++ drivers/media/dvb/mantis/mantis_ca.h | 27 + drivers/media/dvb/mantis/mantis_cards.c| 305 + drivers/media/dvb/mantis/mantis_common.h | 179 +++ drivers/media/dvb/mantis/mantis_core.c | 238 drivers/media/dvb/mantis/mantis_core.h | 57 + drivers/media/dvb/mantis/mantis_dma.c | 256 drivers/media/dvb/mantis/mantis_dma.h | 30 + drivers/media/dvb/mantis/mantis_dvb.c | 296 + drivers/media/dvb/mantis/mantis_dvb.h | 35 + drivers/media/dvb/mantis/mantis_evm.c | 117 ++ drivers/media/dvb/mantis/mantis_hif.c | 240 drivers/media/dvb/mantis/mantis_hif.h | 29 + drivers/media/dvb/mantis/mantis_i2c.c | 267 drivers/media/dvb/mantis/mantis_i2c.h | 30 + drivers/media/dvb/mantis/mantis_input.c| 148 +++ drivers/media/dvb/mantis/mantis_ioc.c | 130 ++ drivers/media/dvb/mantis/mantis_ioc.h | 51 + drivers/media/dvb/mantis/mantis_link.h | 83 ++ drivers/media/dvb/mantis/mantis_pci.c | 177 +++ drivers/media/dvb/mantis/mantis_pci.h | 27 + drivers/media/dvb/mantis/mantis_pcmcia.c | 120 ++ drivers/media/dvb/mantis/mantis_reg.h | 197 +++ drivers/media/dvb/mantis/mantis_uart.c | 186 +++ drivers/media/dvb/mantis/mantis_uart.h | 58 + drivers/media/dvb/mantis/mantis_vp1033.c | 212 drivers/media/dvb/mantis/mantis_vp1033.h | 30 + drivers/media/dvb/mantis/mantis_vp1034.c | 119 ++ drivers/media/dvb/mantis/mantis_vp1034.h | 33 + drivers/media/dvb/mantis/mantis_vp1041.c | 358 ++ drivers/media/dvb/mantis/mantis_vp1041.h | 33 + drivers/media/dvb/mantis/mantis_vp2033.c | 187 +++ drivers/media/dvb/mantis/mantis_vp2033.h | 30 + drivers/media/dvb/mantis/mantis_vp2040.c | 186 +++ drivers/media/dvb/mantis/mantis_vp2040.h | 32 + drivers/media/dvb/mantis/mantis_vp3028.c | 38 + drivers/media/dvb/mantis/mantis_vp3028.h | 33 + drivers/media/dvb/mantis/mantis_vp3030.c | 105 ++ drivers/media/dvb/mantis/mantis_vp3030.h | 30 + 54 files changed, 7801 insertions(+), 1 deletions(-) create mode 100644 drivers/media/dvb/frontends/mb86a16.c create mode 100644 drivers/media/dvb/frontends/mb86a16.h create mode 100644 drivers/media/dvb/frontends/mb86a16_priv.h create mode 100644 drivers/media/dvb/frontends/tda665x.c create mode 100644 drivers/media/dvb/frontends/tda665x.h create mode 100644 drivers/media/dvb/mantis/Kconfig create mode 100644 drivers/media/dvb/mantis/Makefile create mode 100644 drivers/media/dvb/mantis/hopper_cards.c create mode 100644 drivers/media/dvb/mantis/hopper_vp3028.c create mode 100644 drivers/media/dvb/mantis/hopper_vp3028.h create mode 100644 drivers/media/dvb/mantis/mantis_ca.c create mode 100644 drivers/media/dvb/mantis/mantis_ca.h create mode 100644 drivers/media/dvb/mantis/mantis_cards.c create mode 100644 drivers/media/dvb/mantis/mantis_common.h create mode 100644 drivers/media/dvb/mantis/mantis_core.c create mode 100644 drivers/media/dvb/mantis/mantis_core.h create mode 100644 drivers/media/dvb/mantis/mantis_dma.c create mode 100644 drivers/media/dvb/mantis/mantis_dma.h create mode 100644 drivers/media/dvb/mantis/mantis_dvb.c create mode 100644 drivers/media/dvb/mantis/mantis_dvb.h create mode 100644 drivers/media/dvb/mantis/mantis_evm.c create mode 100644 drivers/media/dvb/mantis/mantis_hif.c create mode 100644 drivers/media/dvb/mantis/mantis_hif.h create mode 100644 drivers/media/dvb/mantis/mantis_i2c.c create mode 100644
prof 7300
I had some troubles with a prof 7300 dvb s-2 card. I am running OpenSuse 11.2 with a recent hg copy of the v4l-dvb repository. It was detected as a Hauppauge WinTV instead of a prof 7300. After some runs with info_printk statements I found a problem in linux/drivers/media/video/cx88.c As far as I can understand the code I would say card[core-nr] will always be smaller than ARRAY_SIZE(cx88_boards). Therefore core-boardnr is never looked up from the cx88_subids array. After I removed the check with ARRAY_SIZE the correct card is detected and I can watch tv with both my prof 7300 cards. Can someone confirm if the patch I made is correct or explain what the purpose is of the ARRAY_SIZE check? For search references: I was getting this error in dmesg: cx88[1]/2: dvb_register failed (err = -22) cx88[1]/2: cx8802 probe failed, err = -22 Regards, Joep Admiraal diff -r b76072d765c4 linux/drivers/media/video/cx88/cx88-cards.c --- a/linux/drivers/media/video/cx88/cx88-cards.c Tue Dec 29 18:48:04 2009 + +++ b/linux/drivers/media/video/cx88/cx88-cards.c Sat Jan 16 16:44:36 2010 +0100 @@ -3436,8 +3436,8 @@ /* board config */ core-boardnr = UNSET; - if (card[core-nr] ARRAY_SIZE(cx88_boards)) - core-boardnr = card[core-nr]; + //if (card[core-nr] ARRAY_SIZE(cx88_boards)) + // core-boardnr = card[core-nr]; for (i = 0; UNSET == core-boardnr i ARRAY_SIZE(cx88_subids); i++) if (pci-subsystem_vendor == cx88_subids[i].subvendor pci-subsystem_device == cx88_subids[i].subdevice)
[PATCH] Fixed tm6000 broken build
Hi,
Just bought a HVR-900H (0x2040, 0x6600). This patch fixes the broken build
of the tm6000 driver. It was tested with kernel 2.6.30.
However, the kernel panics when I try to access the device. I will try
to get the time to analyze it further.
Regards,
Oskar Anderö
Signed-off-by: Oskar Anderö oskar.and...@cobwebtech.se
---
diff -r 3a4be7d7dabd linux/drivers/staging/tm6000/tm6000-cards.c
--- a/linux/drivers/staging/tm6000/tm6000-cards.c Sun Jan 03 17:04:42
2010 +
+++ b/linux/drivers/staging/tm6000/tm6000-cards.c Wed Jan 13 20:54:09
2010 +0100
@@ -33,7 +33,6 @@
#include tm6000.h
#include tm6000-regs.h
#include tuner-xc2028.h
-#include tuner-xc5000.h
#define TM6000_BOARD_UNKNOWN 0
#define TM5600_BOARD_GENERIC 1
@@ -45,6 +44,8 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
--
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: prof 7300
On 17 января 2010 16:42:27 joep admiraal wrote: I had some troubles with a prof 7300 dvb s-2 card. I am running OpenSuse 11.2 with a recent hg copy of the v4l-dvb repository. It was detected as a Hauppauge WinTV instead of a prof 7300. After some runs with info_printk statements I found a problem in linux/drivers/media/video/cx88.c As far as I can understand the code I would say card[core-nr] will always be smaller than ARRAY_SIZE(cx88_boards). Therefore core-boardnr is never looked up from the cx88_subids array. After I removed the check with ARRAY_SIZE the correct card is detected and I can watch tv with both my prof 7300 cards. Can someone confirm if the patch I made is correct or explain what the purpose is of the ARRAY_SIZE check? For search references: I was getting this error in dmesg: cx88[1]/2: dvb_register failed (err = -22) cx88[1]/2: cx8802 probe failed, err = -22 Regards, Joep Admiraal Do/did you have another TV tuner? Please check file /etc/modprobe.conf or files in /etc/modprobe.d/ for line like this options cx88xx card=n Then remove the line You can try to check your card modprobe cx88xx card=75 -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: PCTV (ex Pinnacle) 74e pico USB stick DVB-T: no frontend registered
On Sun, Jan 17, 2010 at 5:18 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: The 74e is not a dib0700-based device, my assumption at that time was wrong. For the 74e afaik, there is no LinuxTV driver right now. (IIRC it is a Abilis based design) Patrick is correct in that the 74e is an Abilis design. I have been working with PCTV for a couple of months, who has worked with Abilis to get a GPL driver out there. The firmware redistribution rights have finally been straightened out last Friday, so keep an eye on the KernelLabs.com blog for an announcement in the near future. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld 315U and SAA7113?
On Sun, Jan 17, 2010 at 2:05 AM, Franklin Meng fmeng2...@yahoo.com wrote: I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Either way it looks like I will have to reinitialize the device after switching between interfaces. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. Hello Franklin, Just to be clear, I'm not proposing that you remove the suspend logic. I was suggesting that you should be breaking the change into three separate patches, so that if a problem arises we can isolate whether it is a result of the power management changes. Having a separate patch is especially valuable because you are touching other drivers which are shared by other products. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prof 7300
Do/did you have another TV tuner? Please check file /etc/modprobe.conf or files in /etc/modprobe.d/ for line like this options cx88xx card=n Then remove the line You can try to check your card modprobe cx88xx card=75 Hi Igor, I used to have a Hauppauge card in this system. It is not my own system so I will have a look at it when I am in front of it. Thanks for the quick reply. Joep -- 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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mauro, have you read my thread? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLU1GGAAoJEDX/lZlmjdJl8E0H/R3uhrjOuGT+6HcRWwE7p6aY fL9luyYWG79Vx4/VfBWubt7fAqE9TZ/M8+CRCri5rEPr3x4HtOqW3hrN+pmIfabH 5llg7NcZUzekjFZMRb7zhKOX8ErP4p2H5FxbFTxd8EU7AwlHvYuMXnGbaCncj7mT OOdel4QgkMVFnvaegiQALXT4+hmobjYkMZ6KyPUVsLM5gMVFM0BCQDTXCFN1HSUi cwkflFfaUKanNriGuzc1fsuN8VtMUiH19Nl44rS9+y6eim72ORKn24UECq4unedb LslFASNYe5ATe/o2YA1MdoQWhR7xA6J6rO2EmOtU5y8w6XlytKHvQWm31iSvqqQ= =TWl6 -END PGP SIGNATURE- -- 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
[RESEND PATCH] ir-kbd-i2c: Allow to disable Hauppauge filter through module parameter
Some Hauppauge devices have id=0 so such devices won't work. For such devices add a module parameter that allow to turn off filtering. Signed-off-by: Samuel Rakitničan semiroc...@gmail.com -- Lorem ipsum wintv-radio-ir.diff Description: Binary data
libv4l release: 0.6.4: time to retire some (more) v4l1 drivers
Hi All, I'm very happy to announce the release of libv4l-0.6.4 The main change this release is support for decompression of cpia1 compressed yuv, together with the new gspca support for these bridges, this will allow us to retire the cpia1 v4l1 driver. This release also adds a large number of laptops to the list of laptops whose camera modules are known to be mounted upside down in the frame. Last are some improvements to mr97310a support. libv4l-0.6.4 - * Add more laptop models to the upside down devices table * Add error checking to mr97310a decompression * Increase mr97310a minimum clockdiv upon 3 consecutive decoding errors * Add support for decompressing CPIA1 compressed YUV * Speed up autogain algorithm http://people.fedoraproject.org/~jwrdegoede/libv4l-0.6.4.tar.gz Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH] ir-kbd-i2c: Allow to disable Hauppauge filter through module parameter
Some Hauppauge devices have id=0 so such devices won't work.
For such devices add a module parameter that allow to turn
off filtering.
Signed-off-by: Samuel Rakitničan semiroc...@gmail.com
---
diff -r 82bbb3bd0f0a linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cMon Jan 11 11:47:33 2010 -0200
+++ b/linux/drivers/media/video/ir-kbd-i2c.cSat Jan 16 16:39:14 2010 +0100
@@ -61,6 +61,10 @@
module_param(hauppauge, int, 0644);/* Choose Hauppauge remote */
MODULE_PARM_DESC(hauppauge, Specify Hauppauge remote: 0=black, 1=grey (defaults
to 0));
+static int haup_filter = 1;
+module_param(haup_filter, int, 0644);
+MODULE_PARM_DESC(haup_filter, Hauppauge filter for other remotes, default is 1
(On));
+
#define DEVNAME ir-kbd-i2c
#define dprintk(level, fmt, arg...) if (debug = level) \
@@ -96,24 +100,27 @@
if (!start)
/* no key pressed */
return 0;
- /*
-* Hauppauge remotes (black/silver) always use
-* specific device ids. If we do not filter the
-* device ids then messages destined for devices
-* such as TVs (id=0) will get through causing
-* mis-fired events.
-*
-* We also filter out invalid key presses which
-* produce annoying debug log entries.
-*/
- ircode= (start 12) | (toggle 11) | (dev 6) | code;
- if ((ircode 0x1fff)==0x1fff)
- /* invalid key press */
- return 0;
- if (dev!=0x1e dev!=0x1f)
- /* not a hauppauge remote */
- return 0;
+ if (haup_filter != 0) {
+ /*
+* Hauppauge remotes (black/silver) always use
+* specific device ids. If we do not filter the
+* device ids then messages destined for devices
+* such as TVs (id=0) will get through causing
+* mis-fired events.
+*
+* We also filter out invalid key presses which
+* produce annoying debug log entries.
+*/
+ ircode = (start 12) | (toggle 11) | (dev 6) | code;
+ if ((ircode 0x1fff) == 0x1fff)
+ /* invalid key press */
+ return 0;
+
+ if (dev != 0x1e dev != 0x1f)
+ /* not a hauppauge remote */
+ return 0;
+ }
if (!range)
code += 64;
--
Lorem ipsum
--
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 315U and SAA7113?
OK.. I guess that was a misunderstanding on my part. I will split up the patch and re submit. Thanks, Franklin --- On Sun, 1/17/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Kworld 315U and SAA7113? To: Franklin Meng fmeng2...@yahoo.com Cc: linux-media@vger.kernel.org Date: Sunday, January 17, 2010, 8:28 AM On Sun, Jan 17, 2010 at 2:05 AM, Franklin Meng fmeng2...@yahoo.com wrote: I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Either way it looks like I will have to reinitialize the device after switching between interfaces. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. Hello Franklin, Just to be clear, I'm not proposing that you remove the suspend logic. I was suggesting that you should be breaking the change into three separate patches, so that if a problem arises we can isolate whether it is a result of the power management changes. Having a separate patch is especially valuable because you are touching other drivers which are shared by other products. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about Terratec Aureon 7.1 Universe
I thought I'd ask the list as I hope there might be someone with a clue or a suggestion, as I haven't got any :-) A few years ago I bought a Terratec Aureon 7.1 Universe sound board, but I then had trouble getting it to work properly in Linux and put it aside. Now I attempted to try it out again, especially because of its supposedly high quality vinyl record pre-amplifier, which I would like to use, but it seems that it isn't recognized at all by my Linux system. On a PC platform. I wonder if it is broken, or if there are some special things that needs to be done first? When executing 'lspci' it doesn't show up at all, but there is one LED light showing up on the front of the box that is a part of it. Are you aware of any magic that needs to be done to make it recognized by a Linux system? I have tried to use a few kernel compiles from 2.6.19 to 2.6.33rc4 and I chose to include the following drivers (I'm using Slackware so all packages, including the kernels are generic): CONFIG_SND_ICE1712=y CONFIG_SND_ICE1724=y Or, are you aware of a weakness in the electric parts that may have broken while I stored it? I don't remember what I did right after having bought the board, but I suppose it was at least recognized as I didn't return it as being broken. Terratec has discontinued it so it may not even be possible to repair it, if it is indeed broken. Thank you for your time, Peter -- 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 in pwc_set_shutter_speed v2.6.30.5 and fix
I'm pretty sure this is still broken as of 2.6.32.2 Jef Treece On Tue, 2009-08-25 at 12:07 +0200, Laurent Pinchart wrote: On Sunday 23 August 2009 23:04:00 Jef Treece wrote: I found in recent kernel versions, I think somewhere between 2.6.29.3 and 2.6.30.3, pwc_set_shutter_speed regressed. I was able to fix it with this one-line change (drivers/media/video/pwc/pwc-ctrl.c line 755 in 2.6.30.5 source): ret = send_control_msg(pdev, SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, sizeof(buf)); change to ret = send_control_msg(pdev, SET_LUM_CTL, SHUTTER_MODE_FORMATTER, buf, 1); I hope you find this information useful. This indeed looks like a regression to me. Martin, as you've introduced the problem, could you look into it and send a patch ? There might be other occurrences of wrong integer - sizeof conversions, so please review them carefully. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jan 17 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14009:827966cb093f gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: WARNINGS linux-2.6.33-rc2-armv5-davinci: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-armv5-ixp: WARNINGS linux-2.6.33-rc2-armv5-ixp: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: WARNINGS linux-2.6.32-armv5-omap2: WARNINGS linux-2.6.33-rc2-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: WARNINGS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-mips: WARNINGS linux-2.6.33-rc2-mips: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Status of TT C1501
Hi all, I bought a TechnoTrend C-1501 witch has: Philips tda827x Philips tda10023 Demodulator Philips saa7146ah PCI-Bridge I have got the channel scan working, but I cant get it to tune to a channel. When I tune to a channel this happens: czap -c ~/.czap/czap-final.txt Nederland 1 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' 84 Nederland 1:38800:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:88:89:8004 ERROR: cannot parse service data When I try to scan channels in a mux I get: scandvb -c using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x dumping lists (0 services) Done. According to linuxtv wiki it should just work fine: http://linuxtv.org/wiki/index.php/DVB-C_PCI_Cards This all is at a fedora 12 x86_64 machine, I have already tried the latest v4l-dvb drivers. (my cable company is Ziggo here in the Netherlands (former Casema region)) I hope someone can help me out. Best regards, Sander Vermin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to use saa7134 gpio via gpio-sysfs?
[snip] Damned, seems the opto-isolated I/Os might be in question. For the RTD stuff we don't have any high resolution photographs or anything else ... Gordon, we should wait for, if RTD and Philips/NXP do have a agreement on such. I doubt it, given how it came in. Else, you can of course still do what you ever want on that driver. 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
[PATCH] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following 5 changesets: 01/05: Add Support for DVBWorld DVB-S2 PCI 2004D card http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=199213295c11 02/05: Compro S350 GPIO change http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=84347195a02c 03/05: dm1105: connect splitted else-if statements http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=cd9e72ee99c4 04/05: dm1105: use dm1105_dev dev instead of dm1105dvb http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=5cb9c8978917 05/05: dm1105: use macro for read/write registers http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6ed71bd9d32b dvb/dm1105/Kconfig|1 dvb/dm1105/dm1105.c | 539 +- video/saa7134/saa7134-cards.c |4 3 files changed, 285 insertions(+), 259 deletions(-) Thanks, Igor -- 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] http://mercurial.intuxication.org/hg/v4l-dvb-commits
Am Montag, den 18.01.2010, 01:06 +0200 schrieb Igor M. Liplianin: Mauro, Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following 5 changesets: 01/05: Add Support for DVBWorld DVB-S2 PCI 2004D card http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=199213295c11 02/05: Compro S350 GPIO change http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=84347195a02c 03/05: dm1105: connect splitted else-if statements http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=cd9e72ee99c4 04/05: dm1105: use dm1105_dev dev instead of dm1105dvb http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=5cb9c8978917 05/05: dm1105: use macro for read/write registers http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6ed71bd9d32b dvb/dm1105/Kconfig|1 dvb/dm1105/dm1105.c | 539 +- video/saa7134/saa7134-cards.c |4 3 files changed, 285 insertions(+), 259 deletions(-) Thanks, Igor Igor, What does that one pin more high on your 02/05 exactly? Given that we still have boards, pulling all pins high for fun and then work somehow. It is very wrong to proceed in such a way further. I would disable such stuff next day and did say so previously. The last we need are more undocumented gpio pins. 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
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix for the following 3 changesets: 01/03: ivtv: Fix race condition for queued udma transfers http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix?cmd=changeset;node=0ffbc0331b4d 02/03: cx25840, v4l2-subdev, ivtv, pvrusb2: Fix ivtv/cx25840 tinny audio http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix?cmd=changeset;node=7753cdcebd28 03/03: ivtv: Adjust msleep() delays used to prevent tinny audio and PCI bus hang http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix?cmd=changeset;node=ec42a97b1a36 drivers/media/video/cx25840/cx25840-core.c | 48 +++-- drivers/media/video/ivtv/ivtv-irq.c|5 +-- drivers/media/video/ivtv/ivtv-streams.c|8 +++- drivers/media/video/ivtv/ivtv-udma.c |1 drivers/media/video/pvrusb2/pvrusb2-hdw.c |1 include/media/v4l2-subdev.h|1 6 files changed, 51 insertions(+), 13 deletions(-) Thanks go to Argus for figuring out the causal relationship for the tinny audio problem. Many thanks go to Martin Dauskardt whose extensive testing efforts found optimal time delays for the msleep()s to avoid video artifacts. Thanks, 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
Do any drivers access the cx25840 module in an atomic context?
Hi, I am going to add locking to the cx25840 module register reads and writes because I now have a case where a workqueue, a userpace, and/or the cx25840 firmware loading workqueue could contend for access to the CX2584x or equivalent device. I have identiifed the following drivers that actually use this module: cx231xx, pvrusb2, ivtv, cx23885 Now here's where I need help, since I don't understand the USB stuff too well and there's a lot of code to audit: Do any of these modules call the cx25840 routines with either: a. call the cx25840 module subdev functions with a spinlock held ? or b. call the cx25840 module subdev functions from an interrupt context: i.e. a hard irq or tasklet ? or c. bypass the normal cx25840_read/write calls with direct I2C access to the client address of 0x44 (0x88 1) ? Any definitive confirmation anyone can give on any of these drivers would be helpful and would save me some time. For the cx23885 driver I think these are the answers: a. probably not b. probably not c. yes but I have to double check. I can probably audit the ivtv driver on my own. I understand it's structure, but it's a big driver and will take time to check, if no one knows off hand. The pvrusb2 and cx231xx will be a little harder for me. They aren't terribly large, but I don't understand USB device interrupt contexts. TIA. 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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250
On Sat, 2010-01-16 at 20:26 -0500, Andy Walls wrote: On Sat, 2010-01-16 at 23:56 +0200, Igor M. Liplianin wrote: On 16 января 2010 21:55:52 Andy Walls wrote: I have checked in more changes to http://linuxtv.org/hg/~awalls/cx23885-ir2 Please test again using these module parameters: modprobe cx25840 ir_debug=2 debug=2 modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7 I have removed the spurious interrupt handling code - it was bogus. The real problems are: 1. performing AV Core i2c transactions from an IRQ context is bad 2. the cx25840 module needs locking to prevent i2c transaction contention during the AV Core register reads and writes. I have implemented and checked in a change for #1. Now the AV_CORE interrupt gets disabled and a work handler is scheduled to deal with the IR controller on the AV core. When the work handler is done, it will re-enable the AV_CORE interrupt. I have not implmented a change for #2 yet. I have not added locking to protect cx25840_read() and cx25840_write() functions. This will take time to get right. You may test these latest changes if you want, but I won't be surprised if things don't work on occasion. I have tested IR loopback with my HVR-1250 and things are fine for me, but I have no video interrupts coming in either. Regards, Andy OK. I think I finally have guessed what is going on: 1. The cx23885_irq_handler is called for the AV_CORE when something else in the cx23885 or cx25840 module is accessing that I2C bus. 2. The I2C bus adapter mutex in the i2c_subsystem stays locked so the cx23885_irq_handler() and cx25840_irq_handler() cannot read the AV core registers since the I2C subsystem returns -EINVAL and 0 for the data. 3. The interrupt handler keeps getting called because it never clears the interrupt condition in the AV Core. I think I have to do some work in the cx25840 module and the cx23885 module to handle locking of the AV Core I2C client and I2C bus 3. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC] support for fly dvb duo on medion laptop
Hi list,
this patch add support for lifeview fly dvb duo (hybrid card) on medion
laptop
what works : dvb and analogic tv
not tested : svideo, composite, radio (i am not the owner of this card)
this card uses gpio 22 for the mode switch between analogic and dvb
gpio settings should change when svideo , composite an radio will be
tested
Cheers,
Thomas
Signed-off-by : Thomas Genty tomloh...@gmail.com
diff -r cdcf089168df linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 17 20:42:47 2010 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Mon Jan 18 07:03:53 2010 +0100
@@ -5394,7 +5394,37 @@
.amux = LINE2,
},
},
-
+ [SAA7134_BOARD_FLYDVBTDUO_MEDION] = {
+ /* Thomas Genty tomloh...@gmail.com */
+ .name = LifeView FlyDVB-T DUO Medion,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .gpiomask = 0x0020,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .gpio = 0x20,
+ .tv = 1,
+ },{
+ .name = name_comp1, /* Not tested */
+ .vmux = 3,
+ .amux = LINE1,
+ },{
+ .name = name_svideo, /* Not tested */
+ .vmux = 8,
+ .amux = LINE1,
+ }},
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x00, /* No tested */
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6551,6 +6581,12 @@
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x5168,
+ .subdevice= 0x0307, /* LR307-N */
+ .driver_data = SAA7134_BOARD_FLYDVBTDUO_MEDION,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -7318,6 +7354,7 @@
case SAA7134_BOARD_AVERMEDIA_SUPER_007:
case SAA7134_BOARD_TWINHAN_DTV_DVB_3056:
case SAA7134_BOARD_CREATIX_CTX953:
+ case SAA7134_BOARD_FLYDVBTDUO_MEDION:
{
/* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
diff -r cdcf089168df linux/drivers/media/video/saa7134/saa7134-dvb.c
--- a/linux/drivers/media/video/saa7134/saa7134-dvb.c Sun Jan 17 20:42:47 2010 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134-dvb.c Mon Jan 18 07:03:53 2010 +0100
@@ -825,6 +825,20 @@
.request_firmware = philips_tda1004x_request_firmware
};
+static struct tda1004x_config tda827x_flydvbtduo_medion_config = {
+ .demod_address = 0x08,
+ .invert= 1,
+ .invert_oclk = 0,
+ .xtal_freq = TDA10046_XTAL_16M,
+ .agc_config= TDA10046_AGC_TDA827X,
+ .gpio_config = TDA10046_GP01_I,
+ .if_freq = TDA10046_FREQ_045,
+ .i2c_gate = 0x4b,
+ .tuner_address = 0x61,
+ .antenna_switch = 2,
+ .request_firmware = philips_tda1004x_request_firmware
+};
+
/* --
* special case: this card uses saa713x GPIO22 for the mode switch
*/
@@ -1586,6 +1600,22 @@
dtv1000s_tda18271_config);
}
break;
+ case SAA7134_BOARD_FLYDVBTDUO_MEDION:
+ /* this card uses saa713x GPIO22 for the mode switch */
+ fe0-dvb.frontend = dvb_attach(tda10046_attach,
+ tda827x_flydvbtduo_medion_config,
+ dev-i2c_adap);
+ if (fe0-dvb.frontend) {
+ if (dvb_attach(tda827x_attach,fe0-dvb.frontend,
+ tda827x_flydvbtduo_medion_config.tuner_address, dev-i2c_adap,
+ads_duo_cfg) == NULL) {
+wprintk(no tda827x tuner found at addr: %02x\n,
+ tda827x_flydvbtduo_medion_config.tuner_address);
+goto dettach_frontend;
+ }
+ } else
+ wprintk(failed to attach tda10046\n);
+ break;
default:
wprintk(Huh? unknown DVB card?\n);
break;
diff -r cdcf089168df linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h Sun Jan 17 20:42:47 2010 -0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h Mon Jan 18 07:03:53 2010 +0100
@@ -301,6 +301,7 @@
#define SAA7134_BOARD_ASUS_EUROPA_HYBRID 174
#define SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S 175
#define SAA7134_BOARD_BEHOLD_505RDS_MK3 176
+#define SAA7134_BOARD_FLYDVBTDUO_MEDION 177
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
[Patch 1/3] Kworld 315U
Patch to add the s_power function to the saa7115.c code.
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/saa7115.c
--- a/linux/drivers/media/video/saa7115.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/saa7115.c Sun Jan 17 22:54:21 2010 -0800
@@ -1338,6 +1338,59 @@
return 0;
}
+static int saa711x_s_power(struct v4l2_subdev *sd, int val)
+{
+ struct saa711x_state *state = to_state(sd);
+
+ if(val 1 || val 0)
+ return -EINVAL;
+
+ /* There really isn't a way to put the chip into power saving
+ other than by pulling CE to ground so all we do is return
+ out of this function
+ */
+ if(val == 0)
+ return 0;
+
+ /* When enabling the chip again we need to reinitialize the
+ all the values
+ */
+ state-input = -1;
+ state-output = SAA7115_IPORT_ON;
+ state-enable = 1;
+ state-radio = 0;
+ state-bright = 128;
+ state-contrast = 64;
+ state-hue = 0;
+ state-sat = 64;
+
+ state-audclk_freq = 48000;
+
+ v4l2_dbg(1, debug, sd, writing init values s_power\n);
+
+ /* init to 60hz/48khz */
+ state-crystal_freq = SAA7115_FREQ_24_576_MHZ;
+ switch (state-ident) {
+ case V4L2_IDENT_SAA7111:
+ saa711x_writeregs(sd, saa7111_init);
+ break;
+ case V4L2_IDENT_SAA7113:
+ saa711x_writeregs(sd, saa7113_init);
+ break;
+ default:
+ state-crystal_freq = SAA7115_FREQ_32_11_MHZ;
+ saa711x_writeregs(sd, saa7115_init_auto_input);
+ }
+ if (state-ident != V4L2_IDENT_SAA7111)
+ saa711x_writeregs(sd, saa7115_init_misc);
+ saa711x_set_v4lstd(sd, V4L2_STD_NTSC);
+
+ v4l2_dbg(1, debug, sd, status: (1E) 0x%02x, (1F) 0x%02x\n,
+ saa711x_read(sd, R_1E_STATUS_BYTE_1_VD_DEC),
+ saa711x_read(sd, R_1F_STATUS_BYTE_2_VD_DEC));
+ return 0;
+}
+
static int saa711x_reset(struct v4l2_subdev *sd, u32 val)
{
v4l2_dbg(1, debug, sd, decoder RESET\n);
@@ -1513,6 +1566,7 @@
.s_std = saa711x_s_std,
.reset = saa711x_reset,
.s_gpio = saa711x_s_gpio,
+ .s_power = saa711x_s_power,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.g_register = saa711x_g_register,
.s_register = saa711x_s_register,
--
To unsubscribe from this list: send
[Patch 2/3] Kworld 315U
Patch with updated GPIOs and enable analog inputs for the Kworld 315U
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Thu Dec 31 19:14:54
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Sun Jan 17 22:54:21
2010 -0800
@@ -122,13 +122,31 @@
};
#endif
+/* Kworld 315U
+ GPIO0 - Enable digital power (lgdt3303) - low to enable
+ GPIO1 - Enable analog power (saa7113/emp202) - low to enable
+ GPIO7 - enables something ?
+ GOP2 - ?? some sort of reset ?
+ GOP3 - lgdt3303 reset
+ */
/* Board - EM2882 Kworld 315U digital */
static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
- {EM28XX_R08_GPIO, 0xff, 0xff, 10},
- {EM28XX_R08_GPIO, 0xfe, 0xff, 10},
+ {EM28XX_R08_GPIO, 0x7e, 0xff, 10},
{EM2880_R04_GPO,0x04, 0xff, 10},
{EM2880_R04_GPO,0x0c, 0xff, 10},
- {EM28XX_R08_GPIO, 0x7e, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog1 analog tv */
+static struct em28xx_reg_seq em2882_kworld_315u_analog1[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
+ {EM28XX_R08_GPIO, 0x7d, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
+/* Board - EM2882 Kworld 315U analog2 component/svideo */
+static struct em28xx_reg_seq em2882_kworld_315u_analog2[] = {
+ {EM28XX_R08_GPIO, 0xfd, 0xff, 10},
{ -1, -1, -1, -1},
};
@@ -140,6 +158,14 @@
{ -1, -1, -1, -1},
};
+/* Board - EM2882 Kworld 315U suspend */
+static struct em28xx_reg_seq em2882_kworld_315u_suspend[] = {
+ {EM28XX_R08_GPIO, 0xff, 0xff, 10},
+ {EM2880_R04_GPO,0x08, 0xff, 10},
+ {EM2880_R04_GPO,0x0c, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
static struct em28xx_reg_seq kworld_330u_analog[] = {
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x00, 0xff, 10},
@@ -1314,28 +1340,28 @@
.decoder= EM28XX_SAA711X,
.has_dvb= 1,
[Patch 3/3] Kworld 315U
Patch to bring device out of power saving mode.
Signed-off-by: Franklin Mengfmeng2...@yahoo.com
diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-core.c
--- a/linux/drivers/media/video/em28xx/em28xx-core.c Thu Dec 31 19:14:54
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-core.c Sun Jan 17 22:54:21
2010 -0800
@@ -1132,6 +1132,7 @@
*/
void em28xx_wake_i2c(struct em28xx *dev)
{
+ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 1);
v4l2_device_call_all(dev-v4l2_dev, 0, core, reset, 0);
v4l2_device_call_all(dev-v4l2_dev, 0, video, s_routing,
INPUT(dev-ctl_input)-vmux, 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: [PATCH] Compro S350 GPIO change
2010/1/17 JD Louw jd.l...@mweb.co.za: Hi, This patch enables LNB power on newer revision d1 Compro S350 and S300 DVB-S cards. While I don't have these cards to test with I'm confident that this works. See http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/7471 and http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/14296 and new windows driver as reference. Signed-off-by: JD Louw jd.l...@mweb.co.za diff -r 59e746a1c5d1 linux/drivers/media/video/saa7134/saa7134-cards.c --- a/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Dec 30 09:10:33 2009 -0200 +++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Jan 17 14:51:07 2010 +0200 @@ -7037,8 +7037,8 @@ int saa7134_board_init1(struct saa7134_d break; case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; - saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); - saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); + saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xC000, 0xC000); + saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xC000, 0xC000); break; } return 0; -- Hi Jan, This does not fix the problem where the card is suppose to suspend and the Voltage drops to 0V? Do you still require the windows registry reference for this part? -- 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
