Hi Andy
Andy Walls wrote:
>
> Hi Patrick,
>
> On Tue, 2010-02-09 at 03:35 -0800, Patrick Cairns wrote:
> > Hello
> >
> > I'm testing use of multiple Leadtek WinFast DVR3100 H cards for a
> > project. I've had large numbers of them working well in the same
> > machine as encoders (haven't been using the DVB-T capabilities).
> >
> > However if I use more than a few of these cards in the same machine
> > then upon startup there are always one or two cards where Zarlink
> > zl10353 reading errors are reported preventing their use:-
> >
> > options: enc_yuv_buffers=0 enc_pcm_buffers=0 enc_vbi_buffers=0 radio=0
> enc_idx_buffers=0 enc_mpg_bufsize=64
> >
> > cx18-10: Initializing card 10
> > cx18-10: Autodetected Leadtek WinFast DVR3100 H card
> > cx18 0000:05:09.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > cx18-10: Unreasonably low latency timer, setting to 64 (was 32)
> > cx18-10: cx23418 revision 01010000 (B)
> > cx18-10: Simultaneous DVB-T and Analog capture supported,
> > except when capturing Analog from the antenna input.
> > IRQ 18/cx18-10: IRQF_DISABLED is not guaranteed on shared IRQs
> > cx18-10: Disabled encoder YUV device
> > cx18-10: Disabled encoder VBI device
> > cx18-10: Disabled encoder PCM audio device
> > cx18-10: Disabled encoder IDX device
> > cx18-10: Registered device video10 for encoder MPEG (32 x 64 kB)
> > DVB: registering new adapter (cx18)
> > zl10353_read_register: readreg error (reg=127, ret==-6)
>
> Register 127 is the CHIP_ID register of the Zarlink ZL10353, it is the
> first register the zl10353 driver tries to read. It is returning with
> an error obviously.
>
> > cx18-10: frontend initialization failed
> > cx18-10: DVB failed to register
> > cx18-10: Registered device radio10 for encoder radio
>
> Hmmm. I have to look into why the radio=0 option isn't honored.
yeah, doesn't appear to disable.
>
> > cx18-10: Error -1 registering devices
> > cx18-10: Error -1 on initialization
> > cx18: probe of 0000:05:09.0 failed with error -1
> >
> > Looking/flailing around for more diagnostic information and related
> > posts I tried a few things and found that if I enabled the bit_test in
> > i2c-algo-bit, the second test failed with the offending cards whereas
> > it normally succeeds. I'm not certain this is relevant but it might
> > indicate an underlying fault in card<->driver communication:-
> >
> > cx18-10: Initializing card 10
> > cx18-10: Autodetected Leadtek WinFast DVR3100 H card
> > cx18-10: cx23418 revision 01010000 (B)
> > cx18-10: i2c: i2c init
> > cx18 i2c driver #10-0: Test OK
> > cx18 i2c driver #10-1: bus seems to be busy
> > cx18-10: Could not initialize i2c
> > cx18-10: Error -19 on initialization
>
> This was an excellent test to perform. IIRC, only the ZL10353 and
> XC3028 are on the second I2C bus (#10-1 in this case), which likely
> means one of those two chips is hung.
>
> In the cx18 driver, I have a way of explicitly resetting the XC3028, and
> the driver does reset it. So either the XC3028 may not be all the way
> out of reset yet or the ZL10353 is hung.
>
>
> > Can anyone advise how to debug this further or know any fixes to try?
> > I'm not quite sure what's going on under the hood.
>
>
> In cx18-gpio.c:resetctrl_reset(), find
>
> case CX18_GPIO_RESET_XC2028:
> if (cx->card->tuners[0].tuner == TUNER_XC2028)
> gpio_reset_seq(cx, (1 << cx->card->xceive_pin), 0,
> 1, 1);
>
> and change the "1, 1);" from 1 msec assert and recovery delays to
> something like 30 msec for each. Most likely the recovery delay (the
> second one) will be the one that matters. We want to make sure the
> XC3028 is out of reset before talking on the I2C bus to the ZL10353.
>
I gave that a whirl. That CX18_GPIO_RESET_XC2028 call only seems to get called
later along with the firmware being loaded at the point where the device is
accessing using my v4l application and if I try modifying the times to 30 msec
instead of 1 it doesn't prevent or fix future occurrences of the error (eg if I
reboot/remodprobe the cx18 driver).
>
> I'll have to look at what can be done to reset the ZL10353. I don't know
> if the board has a separate hardware line to the ZL10353, so this may
> not be possible.
>
>
> (I should really also implement hardware master I2C in the cx18 driver
> instead of bit-banging I2C, but I suspect it would be unlikely to have
> an effect on this particular problem.)
>
> > More information:-
> >
> > Tested against Kernel 2.6.32 (our own custom config including
> > increased max dvb adapter count) with or without latest v4l staging
> > development repository overlayed (the above dmesg output is from the
> > default 2.6.32 v4l).
> >
> > The problem almost always persists across soft reboots affecting the
> > same one or two cards each time. A full power cycle however often
> > results in different cards being affected. Reordering cards, varying
> > bus positions/locations (there are 3 buses on my main test system) has
> > no apparent effect on the problem. So there is apparent randomness.
> > Problem has occurred with as few as 4 cards (not sure about 2/3 yet).
> > Sometimes, after a power cycle, no cards are affected, but within a
> > few soft cycles, one or 2 cards become afflicted and the problem
> > remains until power cycled.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Sounds like the ZL10353 getting hung.
>
> So do you need the DVB side at all, or would you be OK with a patch to
> have the card working with only analog baseband (the tuner is on the
> problem I2C bus), if DVB initialization fails?
>
Interesting, yeah although I'll want use of the v4l analogue tuning and perhaps
the DVB frontend for DVB-T later, a patch to bypass this failure and work
without these could be really very useful to me in the short term.
I've learned a little more about how this hangs together from your email,
thanks!
> > I'm now testing a couple of alternative systems to see if the same
> > behaviour occurs there but thought it best at this stage to post for
> > suggestions.
> >
> > Regards
> >
> > Patrick Cairns
>
> Regards,
> Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
