Re: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Robert Lowery
 On Thu, Nov 5, 2009 at 3:57 PM, Vincent McIntyre
 vincent.mcint...@gmail.com wrote:
 I have one of these too.

 lsusb:
 Bus 003 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 003 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)

 In addition I have a DViCO Dual Digital Express which is a PCIe card
 based on Conexant, with the Zarlink frontend.
 lspci:
 04:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
 CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 02)
        Subsystem: DViCO Corporation Device [18ac:db78]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr-
 Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at 9000 (64-bit, non-prefetchable) [size=2M]
        Capabilities: access denied
        Kernel driver in use: cx23885
        Kernel modules: cx23885

 Crap.  This is the price I pay for not having noticed Robert included
 a launchpad ticket with the dmesg output.

 Yeah, it's a zl10353, so I know what the problem is.  Let me look at
 the code and send you a patch for testing.  If you don't hear back
 from me within 24 hours, ping me again.

Do you mean something like this (untested) patch?  I'll try it out tonight.

diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c   Sun Nov 01 07:17:46 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c   Fri Nov 06 10:39:38 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
 };

+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
+   .demod_address = 0x0f,
+   .if2 = 45600,
+   .no_tuner = 1,
+   .parallel_ts = 1,
+   .disable_i2c_gate_ctrl = 1,
+};
+
 static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);

if ((adap-fe = dvb_attach(zl10353_attach,
-  cxusb_zl10353_xc3028_config,
+  cxusb_zl10353_xc3028_config_no_i2c_gate,
   adap-dev-i2c_adap)) == NULL)
return -EIO;


 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



--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Robert Lowery
 On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au
 wrote:
 Do you mean something like this (untested) patch?  I'll try it out
 tonight.

 diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
 --- a/linux/drivers/media/dvb/dvb-usb/cxusb.c   Sun Nov 01 07:17:46 2009
 -0200
 +++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c   Fri Nov 06 10:39:38 2009
 +1100
 @@ -666,6 +666,14 @@
        .parallel_ts = 1,
  };

 +static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate =
 {
 +       .demod_address = 0x0f,
 +       .if2 = 45600,
 +       .no_tuner = 1,
 +       .parallel_ts = 1,
 +       .disable_i2c_gate_ctrl = 1,
 +};
 +
  static struct mt352_config cxusb_mt352_xc3028_config = {
        .demod_address = 0x0f,
        .if2 = 4560,
 @@ -897,7 +905,7 @@
        cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);

        if ((adap-fe = dvb_attach(zl10353_attach,
 -                                  cxusb_zl10353_xc3028_config,
 +                                
  cxusb_zl10353_xc3028_config_no_i2c_gate,
                                   adap-dev-i2c_adap)) == NULL)
                return -EIO;

 Wow, that looks shockingly similar to the patch I did for an em28xx
 boards a couple of months ago, even down to the part where you added
 _no_i2c_gate to the end!  :-)

I might have got some inspiration from somewhere :)


 Yeah, that's the fix, although from the diff I can't tell if you're
 doing it for all zl10353 boards in cxusb.c or just yours.  I would
 have to see the source to know for sure.

I only changed cxusb_dualdig4_frontend_attach() so it should be just my
board.  The only other board that was using cxusb_zl10353_xc3028_config
was cxusb_nano2_frontend_attach(), but I left that as is since I don't
know if that board is similarily affected.

I'l try it out tonight and confirm it fixes the problem

Thanks for your help

-Rob


 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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-05 Thread Robert Lowery
 On Thu, Nov 5, 2009 at 6:45 PM, Robert Lowery rglow...@exemail.com.au
 wrote:
 Do you mean something like this (untested) patch?  I'll try it out
 tonight.

 diff -r 43878f8dbfb0 linux/drivers/media/dvb/dvb-usb/cxusb.c
 --- a/linux/drivers/media/dvb/dvb-usb/cxusb.c   Sun Nov 01 07:17:46
 2009
 -0200
 +++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c   Fri Nov 06 10:39:38
 2009
 +1100
 @@ -666,6 +666,14 @@
        .parallel_ts = 1,
  };

 +static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate =
 {
 +       .demod_address = 0x0f,
 +       .if2 = 45600,
 +       .no_tuner = 1,
 +       .parallel_ts = 1,
 +       .disable_i2c_gate_ctrl = 1,
 +};
 +
  static struct mt352_config cxusb_mt352_xc3028_config = {
        .demod_address = 0x0f,
        .if2 = 4560,
 @@ -897,7 +905,7 @@
        cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);

        if ((adap-fe = dvb_attach(zl10353_attach,
 -                                  cxusb_zl10353_xc3028_config,
 +                                
  cxusb_zl10353_xc3028_config_no_i2c_gate,
                                   adap-dev-i2c_adap)) == NULL)
                return -EIO;

 Wow, that looks shockingly similar to the patch I did for an em28xx
 boards a couple of months ago, even down to the part where you added
 _no_i2c_gate to the end!  :-)

 I might have got some inspiration from somewhere :)


 Yeah, that's the fix, although from the diff I can't tell if you're
 doing it for all zl10353 boards in cxusb.c or just yours.  I would
 have to see the source to know for sure.

 I only changed cxusb_dualdig4_frontend_attach() so it should be just my
 board.  The only other board that was using cxusb_zl10353_xc3028_config
 was cxusb_nano2_frontend_attach(), but I left that as is since I don't
 know if that board is similarily affected.

 I'll try it out tonight and confirm it fixes the problem

Devin,

I have confirmed the patch below fixes my issue.  Could you please merge
it for me?

Thanks

-Rob

Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1)
Signed Off: Robert Lowery rglow...@exemail.com.au

diff -r c57f47cfb0e8 linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c   Wed Nov 04 18:21:15 2009
-0200
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c   Fri Nov 06 13:28:07 2009
+1100
@@ -666,6 +666,14 @@
.parallel_ts = 1,
 };

+static struct zl10353_config cxusb_zl10353_xc3028_config_no_i2c_gate = {
+   .demod_address = 0x0f,
+   .if2 = 45600,
+   .no_tuner = 1,
+   .parallel_ts = 1,
+   .disable_i2c_gate_ctrl = 1,
+};
+
 static struct mt352_config cxusb_mt352_xc3028_config = {
.demod_address = 0x0f,
.if2 = 4560,
@@ -897,7 +905,7 @@
cxusb_bluebird_gpio_pulse(adap-dev, 0x02, 1);

if ((adap-fe = dvb_attach(zl10353_attach,
-  cxusb_zl10353_xc3028_config,
+  cxusb_zl10353_xc3028_config_no_i2c_gate,
   adap-dev-i2c_adap)) == NULL)
return -EIO;


--
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: bisected regression in tuner-xc2028 on DVICO dual digital 4

2009-11-08 Thread Robert Lowery
 On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams bazzaw...@gmail.com
 wrote:
 Hi Devin
 I tried your tree and I seem to get the same problem on one box I get
 the flood of 'dvb-usb: bulk message failed: -110 (1/0'.
 snip

 Can you please confirm the USB ID of the board you are having the
 problem with (by running lsusb from a terminal window)?

 Thanks,

 Devin
 --


 On the first box I have
 Bus 003 Device 003: ID 0fe9:db98 DVICO
 Bus 003 Device 002: ID 0fe9:db98 DVICO

 on the second
 Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4
 (ZL10353+xc2028/xc3028) (initialized)
 --
 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

Barry,

I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78
card.  0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses
completely different hardware and it's behavior is unchanged by my patch
which only targets the rev1 card.

I suspect the problems you are still reporting are from the different
cards, completely unrelated to my fix.

Would you be able to retest after removing the rev2 cards from the machine?

-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


Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-09 Thread Robert Lowery
 Em Mon, 9 Nov 2009 12:13:22 +0100
 Valerio Bontempi valerio.bonte...@gmail.com escreveu:

 Hi all,

 I have a problem trying to user Terratec Cinergy T XS (usb dvb only
 adapter) with XC3028 tuner:
 v4l dvb driver installed in last kernel versions (actually I am using
 2.6.31 from ubuntu 9.10) detects this device but then looks for the
 wrong firmware xc3028-v27.fw, and, moreover, seems to not contain
 correct device firmware at all.
 This makes the device to be detected but dvb device /dev/dvb is not
 created by the kernel.

 Is there a way to make this device to work with last kernel versions
 and last v4l-dvb driver versions?

 Earlier versions of Ubuntu used to contain an out-of-tree driver for
 xc3028,
 that used a different firmware format.

 Due to license issues, distros can't package the firmware files (since the
 vendor
 didn't give any redistribution rights for the firmwares up to now).

 So, you'll need to download a driver with the firmware inside and run a
 script to
 create the firmware.

 For more info and instructions on how to get the firmware, please see:
   
 http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware

 Cheers,
 Mauro

Mauro,

Although the xc3028-v27.fw generated from
HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works fine
for me, the firmware is a couple of years old now and I can't help
wondering if there might be a newer version in the latest Windows drivers
out there containing performance or stability fixes it in.

Do you think it would be worthwhile extracting a newer version of firmware?

-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


Re: [XC3028] Terretec Cinergy T XS wrong firmware xc3028-v27.fw

2009-11-09 Thread Robert Lowery
 On Mon, Nov 9, 2009 at 6:41 PM, Robert Lowery rglow...@exemail.com.au
 wrote:
 Although the xc3028-v27.fw generated from
 HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip using the above process works
 fine
 for me, the firmware is a couple of years old now and I can't help
 wondering if there might be a newer version in the latest Windows
 drivers
 out there containing performance or stability fixes it in.

 Do you think it would be worthwhile extracting a newer version of
 firmware?

 That is the latest version of the firmware for that chip.  Xceive has
 not updated it since then, given that they are focusing on newer
 products like the xc5000 and xc3028L.

 Your problem has nothing to do with the firmware.  The issue is the
 driver support for your particular device was only added recently
 (after Ubuntu did their kernel freeze for Karmic).  The work
 associated with adding support for devices is nontrivial, and I
 typically only do it when people report that their device needs
 support.

 Devin
Sorry Devin,

I shoudn't have hijacked this thread.  My question was general in nature
and not related to the issues being discussed in this thread.

If v2.7 is the latest firmware released by Xceive for the xc3028 then that
answers my question

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


DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-25 Thread Robert Lowery
Hi,

After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screeching audio.

I have traced this issue down to
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
DVB @ 6MHz)

In this change, the offset used by my card has been changed from 275
to 225.

That is, the old code which works used to do something like
offset = 275
if (((priv-cur_fw.type  DTV7) 
(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
((priv-cur_fw.type  DTV78)  freq  47000))



--
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


DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-25 Thread Robert Lowery
Hi,

After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screeching audio.

I have traced this issue down to
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
DVB @ 6MHz)

In this change, the offset used by my card has been changed from 275
to 225.

The old code which works used to do something like
offset = 275
if (((priv-cur_fw.type  DTV7) 
(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
((priv-cur_fw.type  DTV78)  freq  47000))
offset -= 50;

In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
so the subtraction is not done.

The new code which does not work does
if (priv-cur_fw.type  DTV7)
offset = 225;
which appears to be off by 500khz causing the tuning regression for me.

Could any one please advice why this check against scode_table 
(ZARLINK456 | DIBCOM52) was removed?

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


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Robert Lowery
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
 DVB @ 6MHz)
Actually, in addition to the above changeset, I also had to revert
http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
things going.  Seems this one might have been an attempt to fix an issue
introduced by the latter, but for me both must be reverted.

-Rob


 In this change, the offset used by my card has been changed from 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 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



--
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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Robert Lowery
 Hi Rob

 would you mind very much posting a patch that implements these two
 reversions,
 so I can try it easily? My hg-fu is somewhat lacking...
 I have the same hardware and noticed what I think is the same issue,
 just with Channel 9.
 Another manifestation is huge BER and nonzero REC in the output from
 'tzap'.

 Kind regards,
 Vince
revert patch attached



 On 11/26/09, Robert Lowery rglow...@exemail.com.au wrote:
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4
 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d
 everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies
 for
 DVB @ 6MHz)
 Actually, in addition to the above changeset, I also had to revert
 http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
 things going.  Seems this one might have been an attempt to fix an issue
 introduced by the latter, but for me both must be reverted.

 -Rob


 In this change, the offset used by my card has been changed from
 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 ==
 SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 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



 --
 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



revert.diff
Description: Binary data


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-01 Thread Robert Lowery
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I thought
 would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

I got rather different baseline results. All channels had
 significantly higher BER
than I'd noticed before. After patching, snr on some channels
 seemed a little higher
and BER was lower. On ch9, I think snr was up and BER improved a
 little.

   here are the signaltest summary tables:
   without patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.0 %   322.6   672.4  Seven
  191625000 76.0 %   320.2  1783.3  Nine
  21950 76.8 %   329.8  2948.2  Ten
  22650 76.9 %   296.6  4885.0  ABC
  57150 77.0 %   542.0  7529.4  SBS
  57850 77.1 %   539.5 10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.6 % 2.3 0.0
  191625000 77.0 %   235.583.3
  21950 76.9 %   288.0   501.8
  22650 76.9 %   295.1  1416.4
  57150 77.0 %   523.4  3980.0
  57850 77.1 %   549.9  7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 71.2 % 3.1 0.0
  191625000 21.7 %   645.4   246.4
  21950 73.6 % 1.9  1632.0
  22650 73.5 % 2.8  1632.0
  57150 73.9 %13.6  2134.6
  57850 72.7 %58.2  6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 73.2 % 4.0 0.0
  191625000 74.0 %37.0 0.0
  21950 73.9 % 0.0 0.0
  22650 73.0 % 4.6 0.0
  57150 74.2 %76.7   193.6
  57850 72.8 %   213.8  4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
   Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 75.5 %   293.7  1926.4
 191625000 75.9 %   363.2  2993.3
 21950 76.7 %   304.5  4225.8
 22650 76.9 %   223.8  6153.3
 57150 77.0 %   491.7  8726.0
 57850 77.1 %   558.9 11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency   Signal  Ber Unc
 =   
 17750 75.9 %   327.9 13893.6
 191625000 76.0 %   392.8 14939.0
 21950 76.7 %   252.0 16052.0
 22650 76.8 %   254.0 18063.1
 57150 76.9 %   533.2 20644.1
 57850 76.9 %   464.1 23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.3 % 2.5 0.0
 191625000 76.8 %   227.6   119.0
 21950 76.8 %   262.6   604.5
 22650 76.8 %   282.7  1545.4
 57150 77.0 %   486.8  3541.7
 57850 77.1 %   521.5  6537.7


 before patching - adapter1 pciid db78:18ac
 Frequency   Signal  

[RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-07 Thread Robert Lowery
 On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre
 vincent.mcint...@gmail.com wrote:
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I
 thought would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

   I got rather different baseline results. All channels had
 significantly higher BER
   than I'd noticed before. After patching, snr on some channels
 seemed a little higher
   and BER was lower. On ch9, I think snr was up and BER improved a
 little.

  here are the signaltest summary tables:
  without patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.0 %           322.6           672.4  Seven
  191625000         76.0 %           320.2          1783.3  Nine
  21950         76.8 %           329.8          2948.2  Ten
  22650         76.9 %           296.6          4885.0  ABC
  57150         77.0 %           542.0          7529.4  SBS
  57850         77.1 %           539.5         10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.6 %             2.3             0.0
  191625000         77.0 %           235.5            83.3
  21950         76.9 %           288.0           501.8
  22650         76.9 %           295.1          1416.4
  57150         77.0 %           523.4          3980.0
  57850         77.1 %           549.9          7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         71.2 %             3.1             0.0
  191625000         21.7 %           645.4           246.4
  21950         73.6 %             1.9          1632.0
  22650         73.5 %             2.8          1632.0
  57150         73.9 %            13.6          2134.6
  57850         72.7 %            58.2          6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         73.2 %             4.0             0.0
  191625000         74.0 %            37.0             0.0
  21950         73.9 %             0.0             0.0
  22650         73.0 %             4.6             0.0
  57150         74.2 %            76.7           193.6
  57850         72.8 %           213.8          4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
  Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.5 %           293.7          1926.4
 191625000         75.9 %           363.2          2993.3
 21950         76.7 %           304.5          4225.8
 22650         76.9 %           223.8          6153.3
 57150         77.0 %           491.7          8726.0
 57850         77.1 %           558.9         11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.9 %           327.9         13893.6
 191625000         76.0 %           392.8         14939.0
 21950         76.7 %           252.0         16052.0
 22650         76.8 %           254.0         18063.1
 57150         76.9 %           533.2         20644.1
 57850         76.9 %           464.1         23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         76.3 %             2.5             0.0
 191625000         76.8 %           227.6           119.0
 21950         76.8 %           262.6           604.5
 22650         76.8 %           282.7          1545.4
 57150         77.0 %           486.8          3541.7
 57850         77.1 %           521.5          6537.7


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-15 Thread Robert Lowery
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

Thanks

-Rob


01_revert_966ce12c444d.diff
Description: /


02_revert_e6a8672631a0.diff
Description: /


03_refix_e6a8672631a0.diff
Description: /


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-03 Thread Robert Lowery
 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


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-05 Thread Robert Lowery
 On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
 On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
   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
 Robert,
 The changes in question (mostly authored by me) are based on
 documentation on what offsets are to be used with the firmware for
various DVB bandwidths and demodulators.  The change was tested by Terry
 on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
and
 some other cards I can't remember, using a DVB-T pattern generator for
7
 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
(Devin,
  Maybe you can double check on the offsets in tuner-xc2028.c with any
documentation you have available to you?)
 I haven't been following this thread really at all as the board in the
subject line was unfamiliar to me, so sorry for any late response or dumb
questions by me.
 May I ask:
 1. what are the exact problem frequencies?
 2. what is the data source from which you are getting the frequency
information?
 3. what does tuner-xc2028 debug logging show as the firmware loaded
when
 tune to one of the the problem frequencies?


 Robert,

 I just found that ACMA has a very nice compilation licensed DTV
 transmitters in Australia and their frequencies.  Have a look at the
Excel spreadsheet linked on this page:

   http://acma.gov.au/WEB/STANDARD/pc=PC_9150

 The DTV tab has a list of the Area, callsign, and DTV center freq. The
Glossary tab mentions that DTV broadcasters can have an offset of +/- 125
kHz from the DTV center freq.

 If you could verify that the frequencies you are using for the problem
stations match the list, that would help eliminate commanded tuning
frequency as source of the problem.

Andy, I don't think this issue is frequency, it is the removal of the
500kHz offset.

The channel with the biggest problem (most stuttering) is Channel 8 in
Melbourne, which looks correct at 191.625 MHz on the above site.

With debug enabled on the the current hg tip (stuttering case) we have
divisor= 00 00 2f 58 (freq=191.625)

With the patch reverted (working case)
divisor= 00 00 2f 38 (freq=191.625)

Have you reviewed my patch.  It leaves your original DTV6 fix in place,
but reverts the cleanup which broke the offset calculation for me.

-Rob


 Regards,
 Andy


 BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
 cxusb_dvico_xc3028_tuner_attach(), this declaration
 static struct xc2028_ctrl ctl = {
 .fname   = XC2028_DEFAULT_FIRMWARE,
 .max_len = 64,
 .demod   = XC3028_FE_ZARLINK456,
 };
 really should have .type = XC2028_AUTO or .type = XC2028_D2633, but
since XC2028_AUTO has a value of 0, it probably doesn't matter.
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

 --
 To unsubscribe from this list: send the line unsubscribe linux-media
in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html







--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-06 Thread Robert Lowery
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
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
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
 http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.

 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

 OK.  I forgot there were two offsets at play here: one for the RF
 frequency and one for the SCODE/Intermediate Frequency.

 Right, the S-CODE offsets are somewhat of a mystery to me as I don't
 exactly know the mathematical basis behind them.  The 500 kHz came from
 the best interpretation Maruo and I could make at the time, but it could
 very well be the wrong thing.  (I was guessing it came from a relation
 something like this: 8 MHz - 7 MHz / 2 = 500 kHz)

 If it is the wrong thing, and it looks like it could be, we can back it
 out.  As my colleauge, who used to work at CERN, says Experiment trumps
 theory ... *every* time.  Terry had positive results, you and Vincent
 have negative results.  So I'd like to see what Devin finds, if he can
 test with a DVB-T generator.

Andy,

Resend of my proposed patches attached.

My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just
change the ATSC test to DTV6 but at the same time a cleanup that was done
inadvertently removed the 500kHz offset subtraction for DTV7 introducing
the defect.  01_revert_966ce12c444d.diff partially fixed this regression
for Terry, but not for me or Vincent.

I'm having trouble convincing Mauro of this though :), so I would
appreciate it if Terry could test my patch set and confirm it is ok for
him.

So in short, my 01 and 02 patches attached revert the changes that break
tuning for me and 03 re-implements the DTV6 fix, but without the cleanup
which breaks me.

Please review and comment

-Rob




 The channel with the biggest problem (most stuttering) is Channel 8 in
 Melbourne, which looks correct at 191.625 MHz on the above site.

 OK.  Vincent must have been the one with all the Sydney stations.

 DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is
 interesting; it comes from the same towers as the adjacent analog
 channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200
 kW).

 I guess if anything is off center when setting up the XC3028, the analog
 stations may show up as strong noise - a situation that would not be
 obvious with a single channel DVB-T signal generator.  GTV8 is probably
 a good channel for you to use for testing.


 (BTW, given that the analog channel

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Robert Lowery
 patch should be:
     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          else if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;
 Terry
 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,
    The 6MHz patch is for Taiwan only.
    It should not change anything for 7MHz and 8MHz.
 Terry
 2010/1/7 Robert Lowery rglow...@exemail.com.au:
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
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
  Robert,
  The changes in question (mostly authored by me) are based on
documentation on what offsets are to be used with the firmware
 for
 various DVB bandwidths and demodulators.  The change was tested by
Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353,
 XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern
 generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for
6
 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c
 with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board
 in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the
 frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware
 loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
transmitters in Australia and their frequencies.  Have a look at
 the
 Excel spreadsheet linked on this page:
 
     http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center
 freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the
 problem
 stations match the list, that would help eliminate commanded
tuning
 frequency as source of the problem.
 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.
 OK.  I forgot there were two offsets at play here: one for the RF
frequency and one for the SCODE/Intermediate Frequency.
 Right, the S-CODE offsets are somewhat of a mystery to me as I
don't
 exactly know the mathematical basis behind them.  The 500 kHz came
from
 the best interpretation Maruo and I could make at the time, but it
could
 very well be the wrong thing.  (I was guessing it came from a relation
 something like this: 8 MHz - 7 MHz / 2 = 500 kHz)
 If it is the wrong thing, and it looks like it could be, we can
back
 it
 out.  As my colleauge, who used to work at CERN, says Experiment
trumps
 theory ... *every* time.  Terry had positive results, you and Vincent
 have negative results.  So I'd like to see what Devin finds, if he can
 test with a DVB-T generator.
 Andy,
 Resend of my proposed patches attached.
 My hypothesis is that 02_revert_e6a8672631a0.diff was really meant
to
 just
 change the ATSC test to DTV6 but at the same time a cleanup that was
done
 inadvertently removed the 500kHz offset subtraction for DTV7
introducing
 the defect.  01_revert_966ce12c444d.diff partially fixed this
regression
 for Terry, but not for me or Vincent.
 I'm having trouble convincing Mauro of this though :), so I would
appreciate it if Terry could test my patch set and confirm it is ok
for
 him.
 So in short, my 01 and 02 patches attached revert the changes that
break
 tuning for me and 03 re-implements the DTV6 fix, but without the
cleanup
 which breaks me.
 Please review and comment
 -Rob
 The channel with the biggest problem (most stuttering) is Channel
8
 in
 Melbourne, which looks correct at 191.625 MHz on the above site.
 OK.  Vincent must have been the one with all the Sydney stations.
DTV Channel GTV8 (Fc

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-18 Thread Robert Lowery
 Robert Lowery wrote:
 Mauro's new code does the 50 offset unconditionally for DTV7 by
 setting offset = 225, not just when the ZARLINK456 or DIBCOM52
 tables
 were explicitly selected.  This change is what appears to cause issues
 for
 me.

 I've reviewed all information and troubles we have with xc3028 tuning,
 including the reports related to newer firmwares for XC3028L. I think
 that the right fix is the one provided on this patch.

 Could you all please verify if this patch fixes the issues, without
 causing
 any regression?

Thanks Mauro,  I'll test this ASAP.

I suspect there will still be issues with the demod + 500 shift in my
scenario as I had to remove this in the past when changing the offset back
to 275 or else I could not get a tuning lock.

I'll let you know.

-Rob

 Cheers,
 Mauro.

 ---

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/common/tuners/tuner-xc2028.c |   51
 
  1 files changed, 37 insertions(+), 14 deletions(-)

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..eb782a0 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version = 0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 50;
 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
 --
 1.6.6.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Robert Lowery
Mauro,

I had to make 2 changes to get the patch to work for me

see below

HTH

-Rob

 Robert Lowery wrote:
 Mauro's new code does the 50 offset unconditionally for DTV7 by
 setting offset = 225, not just when the ZARLINK456 or DIBCOM52
 tables
 were explicitly selected.  This change is what appears to cause issues
 for
 me.

 I've reviewed all information and troubles we have with xc3028 tuning,
 including the reports related to newer firmwares for XC3028L. I think
 that the right fix is the one provided on this patch.

 Could you all please verify if this patch fixes the issues, without
 causing
 any regression?

 Cheers,
 Mauro.

 ---

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/common/tuners/tuner-xc2028.c |   51
 
  1 files changed, 37 insertions(+), 14 deletions(-)

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..eb782a0 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version = 0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 50;
This should be offset += 50;

 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
I had to also delete the
if (type  DTV7)
demod += 500

I suspect this is no longer required due to the offset += 50 above
 --
 1.6.6.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Robert Lowery
 Robert Lowery wrote:
 Mauro,

 I had to make 2 changes to get the patch to work for me

 Ok. Please test this (hopefully) final revision.

This version works for me

 --

 commit bd8bb8798bb96136b6898186d505c9e154334b5d
 Author: Mauro Carvalho Chehab mche...@redhat.com
 Date:   Fri Feb 19 02:45:00 2010 -0200

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..ef61815 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,52 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version  0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset += 50;
 +#if 0
 + /* Still need some tests */
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 +#endif
 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,17 +1136,22 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
 -  * Thanks to Terry Wu terrywu2...@gmail.com for reporting this
*
* DTV7 is only used in Australia.  Germany or Italy may also
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
 +  *
 +  * Unfortunately, on real-field tests, the s-code offset
 +  * didn't work as expected, as reported by
 +  * Robert Lowery rglow...@exemail.com.au
*/
 - if (type  DTV7)
 - demod += 500;
   }

   return generic_set_freq(fe, p-frequency,
 --
 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