Re: DTV2000 H Plus issues
istva...@mailbox.hu wrote:
On 01/02/2010 05:10 PM, Raena Lea-Shannon wrote:
I have 2 TV Cards. The DTV2000 H Plus and a Technisat. The Technisat
works very well. I am trying to get the DVT working for other video
input devices such as VCR to make copies of old Videos and an inteface
for my N95 video out.
I do not seem to be able to get it to find a tuner. Seems to be problem
finding the card. Any suggestions wold be greatly appreciated.
This card uses an Xceive XC4000 tuner, which is not supported yet.
However, a driver for the tuner chip is being developed at
kernellabs.com, so the card may become supported in the future.
--
[snip]
That seems odd. This patch on the LinuxTv site
http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html
seems to be using the cx88 drivers?
Has anyone tried this patch?
Ta
Raena
# HG changeset patch
# User plr.vincent at gmail.com
# Date 1212398724 -7200
# Node ID 78a011dfba127b593b6d01ea6a0010fcc29c94ad
# Parent 398b07fdfe79ff66a8c1bf2874de424ce29b9c78
WinFast DTV2000 H: add support for missing analog inputs
From: Vincent Pelletier plr.vincent at gmail.com
Add support for the following inputs:
- radio tuner
- composite 1 2 (only 1 is physicaly available, but composite 2 is also
advertised by windows driver)
- svideo
Signed-off-by: Vincent Pelletier plr.vincent at gmail.com
diff -r 398b07fdfe79 -r 78a011dfba12
linux/drivers/media/video/cx88/cx88-cards.c
--- a/linux/drivers/media/video/cx88/cx88-cards.c Wed May 28
17:55:13 2008 -0300
+++ b/linux/drivers/media/video/cx88/cx88-cards.c Mon Jun 02
11:25:24 2008 +0200
@@ -1297,7 +1297,35 @@
.gpio1 = 0x8203,
.gpio2 = 0x00017304,
.gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_COMPOSITE1,
+ .vmux = 1,
+ .gpio0 = 0x0001D701,
+ .gpio1 = 0xB207,
+ .gpio2 = 0x0001D701,
+ .gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_COMPOSITE2,
+ .vmux = 2,
+ .gpio0 = 0x0001D503,
+ .gpio1 = 0xB207,
+ .gpio2 = 0x0001D503,
+ .gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_SVIDEO,
+ .vmux = 3,
+ .gpio0 = 0x0001D701,
+ .gpio1 = 0xB207,
+ .gpio2 = 0x0001D701,
+ .gpio3 = 0x0200,
}},
+ .radio = {
+.type = CX88_RADIO,
+.gpio0 = 0x00015702,
+.gpio1 = 0xF207,
+.gpio2 = 0x00015702,
+.gpio3 = 0x0200,
+ },
.mpeg = CX88_MPEG_DVB,
},
[CX88_BOARD_GENIATECH_DVBS] = {
--
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: DTV2000 H Plus issues
On Sun, 03 Jan 2010 09:21:21 +0100, Raena Lea-Shannon r...@internode.on.net wrote: istva...@mailbox.hu wrote: On 01/02/2010 05:10 PM, Raena Lea-Shannon wrote: I have 2 TV Cards. The DTV2000 H Plus and a Technisat. The Technisat works very well. I am trying to get the DVT working for other video input devices such as VCR to make copies of old Videos and an inteface for my N95 video out. I do not seem to be able to get it to find a tuner. Seems to be problem finding the card. Any suggestions wold be greatly appreciated. This card uses an Xceive XC4000 tuner, which is not supported yet. However, a driver for the tuner chip is being developed at kernellabs.com, so the card may become supported in the future. -- [snip] That seems odd. This patch on the LinuxTv site http://www.linuxtv.org/pipermail/linux-dvb/2008-June/026379.html seems to be using the cx88 drivers? [...] Hi, I'm not a developer, but I think that your device uses both of these chips. cx88 is the bridge chip, while the Xceive is the tuner chip. So, both of them needs to be supported in order for a device to work properly. Please see the following link for reference: http://www.kernellabs.com/blog/?p=1045 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
Slovak Republic DVB-T updates
Hi all, in Slovak Republic there are some updates regarding DVB-T. On 22.12.2009 has been DVB-T officially started in some new cities + existing transmission has been changed as well. updated ones: - Bratislava - Kosice - Banska Bystrica new ones: - Bardejov - Michalovce - Namestovo - Poprad - Rimavska Sobota - Trencin - Velky Krtis - Zilina updates were made based on official announcement (sorry is slovak): http://dvbt.towercom.sk/odbornici.php?article=32 Attached are dvb-t config files for all these. Please include them to official list if possible. I've tested Kosice setting only and it works OK for me. Kind regards Peter Butkovic sk-BanskaBystrica Description: Binary data sk-Bardejov Description: Binary data sk-Bratislava Description: Binary data sk-Kosice Description: Binary data sk-Michalovce Description: Binary data sk-Namestovo Description: Binary data sk-Poprad Description: Binary data sk-RimavskaSobota Description: Binary data sk-Trencin Description: Binary data sk-VelkyKrtis Description: Binary data sk-Zilina Description: Binary data
dvb-apps: add scan file for Kojal, Czech Republic
# HG changeset patch # User Jiri Slaby jirisl...@gmail.com # Date 1262532622 -3600 # Node ID 5f093a32da807e2e324e978e36ab092402aece6f # Parent a66ed623e524395f3805ce6266354f9e52913941 add scan file for Kojal, Czech Republic diff -r a66ed623e524 -r 5f093a32da80 util/scan/dvb-t/cz-Kojal --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/cz-Kojal Sun Jan 03 16:30:22 2010 +0100 @@ -0,0 +1,8 @@ +# DVB-T Kojal (Brno, Czech Republic) +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +# CT - Ceska televize (multiplex 1) +T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# CRa - Ceske radiokomunikace (multiplex 2) +T 62600 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# Czech Digital Group (multiplex 3) +T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE
[PATCH] V4L/DVB (12930): Wrong variable tested
The return of saa7164_i2caddr_to_reglen() was not tested.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/media/video/saa7164/saa7164-api.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/saa7164/saa7164-api.c
b/drivers/media/video/saa7164/saa7164-api.c
index 6f094a9..1d487c1 100644
--- a/drivers/media/video/saa7164/saa7164-api.c
+++ b/drivers/media/video/saa7164/saa7164-api.c
@@ -523,7 +523,7 @@ int saa7164_api_i2c_write(struct saa7164_i2c *bus, u8 addr,
u32 datalen,
}
reglen = saa7164_i2caddr_to_reglen(bus, addr);
- if (unitid 0) {
+ if (reglen 0) {
printk(KERN_ERR
%s() error, cannot translate regaddr to reglen\n,
__func__);
--
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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Sat, 2 Jan 2010, Sean wrote:
Hmm, I applied the changes and I did not see a place where *prev differs
from td-td_hash. I have run memtest86+ on this box and it has passed 16
times, so I do not suspect a hardware memory error. What do you think?
Attached is the latest dmesg output.
I don't know. The same pattern as before appears here:
$ egrep -n '[1b]e(40|5c)' dmesg3.log
167:kobject: 'fs' (c7801e40): kobject_add_internal: parent: 'NULL', set:
'NULL'
4990:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6691e40
5023:ohci_hcd :00:0b.0: hash c6691e40 to 57 - (null)
5181:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676be40
5214:ohci_hcd :00:0b.0: hash c676be40 to 57 - c6691e40
5271:ohci_hcd :00:0b.0: td free c6691e40
5272:ohci_hcd :00:0b.0: (57 1) c676be5c - (null) [(null)]
5294:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6691e40
5327:ohci_hcd :00:0b.0: hash c6691e40 to 57 - c676be40
5533:ohci_hcd :00:0b.0: td free c676be40
5534:ohci_hcd :00:0b.0: (57 1) c6691e5c - (null) [(null)]
5556:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676be40
5589:ohci_hcd :00:0b.0: hash c676be40 to 57 - c6691e40
5640:ohci_hcd :00:0b.0: td free c6691e40
5641:ohci_hcd :00:0b.0: (57 1) c676be5c - c676be40 [c676be40]
5713:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6691e40
5746:ohci_hcd :00:0b.0: hash c6691e40 to 57 - c676be40
5899:ohci_hcd :00:0b.0: td free c676be40
5900:ohci_hcd :00:0b.0: (57 1) c6691e5c - c676be40 [c676be40]
At line 5641 we see that the td_hash pointer in c676be40 gets
corrupted. It is copied from the pointer in c6691e40, which was set to
NULL in line 5534, but now it points to c676be40.
The question is whether this corruption was caused by a hardware fault
or a software bug. We have added debugging printouts to the only two
places where the driver assigns anything to td-td_hash, and they don't
show anything wrong. This leads me to suspect the hardware, but of
course this is still just a guess.
Here is a completely new patch. This one is more directed, to catch
the sort of errors we now know to look for.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-mem.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-mem.c
+++ usb-2.6/drivers/usb/host/ohci-mem.c
@@ -98,17 +98,56 @@ td_alloc (struct ohci_hcd *hc, gfp_t mem
return td;
}
+static void td_check(struct ohci_hcd *hc, int hash, char *msg)
+{
+ struct td *td, *first;
+
+ first = hc-td_hash[hash];
+ for (td = first; td; td = td-td_hash) {
+ if (td-td_hash == first || td-td_hash == td) {
+ ohci_err(hc, Circular pointer %s: %d %p %p %p\n,
+ msg, hash, first, td, td-td_hash);
+ td-td_hash = NULL;
+ return;
+ }
+ }
+}
+
+static void td_check_all(struct ohci_hcd *hc, char *msg)
+{
+ int hash;
+
+ for (hash = 0; hash TD_HASH_SIZE; ++hash)
+ td_check(hc, hash, msg);
+}
+
static void
td_free (struct ohci_hcd *hc, struct td *td)
{
- struct td **prev = hc-td_hash [TD_HASH_FUNC (td-td_dma)];
+ int hash = TD_HASH_FUNC(td-td_dma);
+ struct td **prev = hc-td_hash[hash];
- while (*prev *prev != td)
+ td_check(hc, hash, #1a);
+ while (*prev *prev != td) {
+ if ((unsigned long) *prev == 0xa7a7a7a7) {
+ ohci_err(hc, poisoned hash at %p (%d) %p %p\n, prev,
+ hash, td, hc-td_hash[hash]);
+ return;
+ }
prev = (*prev)-td_hash;
- if (*prev)
+ }
+ if (*prev) {
*prev = td-td_hash;
+ if (*prev == td) {
+ ohci_err(hc, invalid hash at %p (%d) %p %p\n, prev,
+ hash, td, hc-td_hash[hash]);
+ *prev = NULL;
+ }
+ }
else if ((td-hwINFO cpu_to_hc32(hc, TD_DONE)) != 0)
ohci_dbg (hc, no hash for td %p\n, td);
+ mb();
+ td_check(hc, hash, #1b);
dma_pool_free (hc-td_cache, td, td-td_dma);
}
Index: usb-2.6/drivers/usb/host/ohci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-q.c
+++ usb-2.6/drivers/usb/host/ohci-q.c
@@ -558,12 +558,14 @@ td_fill (struct ohci_hcd *ohci, u32 info
/* hash it for later reverse mapping */
hash = TD_HASH_FUNC (td-td_dma);
+ td_check(ohci, hash, #2a);
td-td_hash = ohci-td_hash [hash];
ohci-td_hash [hash] = td;
/* HC might read the TD (or cachelines) right away ... */
wmb ();
td-ed-hwTailP = td-hwNextTD;
+ td_check(ohci, hash, #2b);
}
/*-*/
@@ -1127,9 +1129,11 @@
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
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 3 19:00:03 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e 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: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS 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.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS 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.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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
[PATCH] rj54n1cb0c: remove compiler warning
From: Márton Németh nm...@freemail.hu Remove the following compiler warning: 'dummy' is used uninitialized in this function. Although the result in the dummy variable is not used the program flow in soc_camera_limit_side() depends on the value in dummy. The program flow is better to be deterministic. Signed-off-by: Márton Németh nm...@freemail.hu --- diff -r 62ee2b0f6556 linux/drivers/media/video/rj54n1cb0c.c --- a/linux/drivers/media/video/rj54n1cb0c.cWed Dec 30 18:19:11 2009 +0100 +++ b/linux/drivers/media/video/rj54n1cb0c.cSun Jan 03 21:30:20 2010 +0100 @@ -563,7 +563,7 @@ struct i2c_client *client = sd-priv; struct rj54n1 *rj54n1 = to_rj54n1(client); struct v4l2_rect *rect = a-c; - unsigned int dummy, output_w, output_h, + unsigned int dummy = 0, output_w, output_h, input_w = rect-width, input_h = rect-height; int ret; -- 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
czap needs #define _GNU_SOURCE
Hi, The czap utility (dvb-apps/util/szap/czap.c) cannot scan the channel configuration file when compiled on Fedora 12 with gcc-4.4.2. Problem is tha the sscanf function uses the %a[^:] format specifier. According to man sscanf you need to define _GNU_SOURCE if you want this to work because it is a gnu-only extension. Adding a first line #define _GNU_SOURCE to czap.c and recompiling solves the problem. Cheers, Klaas -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Am Donnerstag, 31. Dezember 2009 20:40:15 schrieb Andy Walls: On Thu, 2009-12-31 at 14:26 -0500, Andy Walls wrote: On Thu, 2009-12-31 at 18:15 +0100, Martin Dauskardt wrote: Some corrections to errors: My preferences in summary, is that not matter what the digitizer chip: My preferences are, in summary, that no matter what the digitizer chip: a. I'd like to keep the audio clocks always up to avoid tinny audio. b. I'd also like to inhibit the video clock and add the delay after ^^^ refine re-enabling the digitizer to avoid the *potential* for a hung machine. A value smaller than 300 ms should work, but a value smaller than 40 ms may not work, if my hypothesis is correct. c. I do not care to much about the delay after disbaling the video clock, only that it is empirically long enough. Thanks for taking the time to test and comment. Regards, Andy Regards, Andy I tested various sleep values: http://home.arcor-online.de/martin.dauskardt/digitizer_msleep.xls It seems that we only need a total delay of 300ms between the previous actions in ivtv-streams.c and the start of the capture. This also secures that we don't see disturbance from a previous frequency switch. This happens with smaller sleep values: http://home.arcor-online.de/martin.dauskardt/channelswitch.mpg and can lead to the infamous flickering problem (http://www.gossamer- threads.com/lists/ivtv/devel/32970) . The current driver has this problem only with cx23415 (PVR350), not cx23416. My preference is: -let it how it is (300 ms sleep before the firmware call) or -split the 300ms to 150 and 150 Greets, Martin -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote: Here is a completely new patch. This one is more directed, to catch the sort of errors we now know to look for. Alan Stern Alan, I applied the patches and ran capture-example twice. On the second run of capture-example a circular pointer popped up. I did not need to remove the camera. Attached are the serial console capture as well as the dmesg log in debug4.tar.gz. Did you want me to try to reproduce the poison message? Sean debug4.tar.gz Description: Unix tar archive
Lenovo compact webcam 17ef:4802
I have not been able to get an image from a Lenovo webcam under Fedora 11. It reports to the kernel with USB id 17ef:4802 as below: kernel: usb 1-3: new high speed USB device using ehci_hcd and address 9 kernel: usb 1-3: New USB device found, idVendor=17ef, idProduct=4802 kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 kernel: usb 1-3: Product: Lenovo USB Webcam kernel: usb 1-3: Manufacturer: Primax kernel: usb 1-3: configuration #1 chosen from 1 choice kernel: gspca: probing 17ef:4802 kernel: vc032x: check sensor header 20 kernel: vc032x: Sensor ID 143a (3) kernel: vc032x: Find Sensor MI1310_SOC kernel: gspca: probe ok When I try to access the web cam with cheese or skype I get the following error in /var/log/messages: gspca: frame overflow 332800 331776 Sometimes cheese shows an image resolution under the preferences menu option. If the resolution is shown, then cheese will display a black image. If I run gstreamer-properties from the command line, it complains of missing plugins: gstreamer-properties-Message: Skipping unavailable plugin 'artsdsink' gstreamer-properties-Message: Skipping unavailable plugin 'esdsink' gstreamer-properties-Message: Skipping unavailable plugin 'glimagesink' gstreamer-properties-Message: Skipping unavailable plugin 'v4lmjpegsrc' gstreamer-properties-Message: Skipping unavailable plugin 'qcamsrc' gstreamer-properties-Message: Skipping unavailable plugin 'esdmon' Are these significant? What package would supply them? //Bill -- 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
cx18: Need information on SECAM-D/K problem with PVR-2100
Sergey, On IRC you mentioned a problem of improper detection of SECAM-D/K with the Leadtek PVR2100 (XC2028 and CX23418) from an RF source. To investigate this problem on my own, I added SECAM support to the saa7127 driver so a PVR-350 could generate a baseband SECAM signal for me. The good news for me is that a PVR-350 (SAA7115 video decoder) and HVR-1600 (CX23418 integrated video decoder) card both properly recognized the output of the PVR-350 as SECAM. The bad news is I could not reproduce your problem with this setup. Could you please do the following and send me the output from the logs? 1. Unload the cx18 module, tuner-xc2028 module, and the other tuner modules. 2. In /etc/modprobe.conf set the following options tuner-xc2028 debug=1 options tuner debug=1 3. Then # modprobe cx18 debug=0x33 info, warn, ioctl, file # v4l2-ctl -d /dev/video0 -i 0 Tuner input # v4l2-ctl -d /dev/video0 -s 18 SECAM-D/K # v4l2-ctl -d /dev/video0 -f freq of good channel # v4l2-ctl -d /dev/video0 --log-status And send the relevant output from dmesg and /var/log/messages, preferably to the mailing list. I do not need the lines that begin cx18-0 encoder MPEG: VIDIOC_QUERYCTRL if that makes the output smaller. 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
Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
Mauro, I've split the revert2.diff that I sent you previously to fix the tuning regression on my DViCO Dual Digital 4 (rev 1) into three separate patches that will hopefully allow you to review more easily. The first two patches revert their respective changesets and nothing else, fixing the issue for me. 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz The third patch does what I believe is the obvious equivalent fix to e6a8672631a0 but without the cleanup that breaks tuning on my card. Please review and merge Signed-off-by: Robert Lowery rglow...@exemail.com.au Mauro, I'm yet to receive a response from you on this clear regression introduced in the 2.6.31 kernel. You attention would be appreciated Thanks -Rob Thanks -Rob -- 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
