> This is the device that Chris wrote the patch for. He has tested the device,
> using cxusb_dee1601_demod_init . Strange..... cxusb_mt352_demod_init is for
> the other two fusionhdtv dvb-t boxes, it probably needs this change as well,
> but I have no device to test with. (I wrote that patch, and it was tested on
> the list). Since I copied this function from cx88-dvb.c , the
> mt352_demod_init functions there might need this as well. Maybe Chris can
> tell us something - he wrote the mt352 stuff in cx88-dvb as well.....
Graham is actually only changing one bit - we do program that register in
the "clock_config" write. It depends on the particular hardware's
configuration. It decides whether the MT352 emits a serial stream (on one
pin) or a parallel stream (on 8 pins).
> Would you test the above change on your device and let us know what happens?
> It looks like this change should be made across the board. If this is needed
> everywhere, maybe we can centralize it for every implementation... What do you
> think?
All the hardware I have had access to and tested on has had a serial
connection to the MT352 (bt8xx can only have a serial connection), and
some cx88-based boards have had both parallel and serial - but the
parallel interface is broken (one hardware revision of a cx88-based
K-World board springs to mind). If you change it for all cards, then you
will induce other problems.
Patrick, this code was tested and I have been using the USB part of the
DViCO Dual Digital board as my sole capture device for a month now. It
has been running with the MT352 in the serial mode - and have not
experienced any of the problems Graham as had.
Nonetheless, I have now tested the Dual Digital board with the patch below
(the CONFIG register immediately follows CLOCK_CTL, so we don't need a
separate entry to write it), and confirmed that it also works in the
parallel (0x28) mode for me.
I can only speculate that there may be a digital noise problem in Graham's
computer that causes corruption when faced with the higher baud rate of
the serial stream. Because the USB part seems to work either way, using
the parallel stream is a more (noise) resilient choice.
Graham, can you confirm that the patch below works for you? If not, then
the problem lies elsewhere - can you see if increasing the udelay from 200
immediately after the clock_config write to a higher value makes any
difference for you? Note you actually have to cold reset the device for
the initialisation code to be called, as the mt352 init code is called
only once per hardware device (unless the device is powered down).
Regards,
Chris
Index: cxusb.c
===================================================================
RCS file: /cvs/video4linux/v4l-dvb/linux/drivers/media/dvb/dvb-usb/cxusb.c,v
retrieving revision 1.22
diff -u -r1.22 cxusb.c
--- cxusb.c 22 Jan 2006 18:10:39 -0000 1.22
+++ cxusb.c 3 Feb 2006 15:05:45 -0000
@@ -234,7 +234,7 @@
static int cxusb_dee1601_demod_init(struct dvb_frontend* fe)
{
- static u8 clock_config [] = { CLOCK_CTL, 0x38, 0x38 };
+ static u8 clock_config [] = { CLOCK_CTL, 0x38, 0x28 };
static u8 reset [] = { RESET, 0x80 };
static u8 adc_ctl_1_cfg [] = { ADC_CTL_1, 0x40 };
static u8 agc_cfg [] = { AGC_TARGET, 0x28, 0x20 };
