* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
@ 2010-02-09 15:19 Patrick Cairns
2010-02-09 15:25 ` Devin Heitmueller
2010-02-13 23:28 ` Andy Walls
0 siblings, 2 replies; 8+ messages in thread
From: Patrick Cairns @ 2010-02-09 15:19 UTC (permalink / raw)
To: Andy Walls; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-09 15:19 Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6) Patrick Cairns
@ 2010-02-09 15:25 ` Devin Heitmueller
2010-02-10 20:29 ` Andy Walls
2010-02-13 23:28 ` Andy Walls
1 sibling, 1 reply; 8+ messages in thread
From: Devin Heitmueller @ 2010-02-09 15:25 UTC (permalink / raw)
To: Patrick Cairns; +Cc: Andy Walls, linux-media
On Tue, Feb 9, 2010 at 10:19 AM, Patrick Cairns
<patrick_cairns@yahoo.com> wrote:
> 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
Are we sure the zl10353 is being reset at all? I've seen cases before
where the zl10353 can hang the entire i2c bus ( in particular with the
i2c_gate_ctrl issue), and the only path to recovery is strobing the
chip reset. It's possible that the GPIO for resetting the zl10353 is
just *wrong* because somebody copied it from some other board profile,
and the chip is never being reset.
Oh, on an unrelated note, I believe the required xc3028 reset strobe
time is supposed to be 10ms, but I would have to double check the docs
to confirm.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-09 15:25 ` Devin Heitmueller
@ 2010-02-10 20:29 ` Andy Walls
2010-02-11 3:31 ` Andy Walls
0 siblings, 1 reply; 8+ messages in thread
From: Andy Walls @ 2010-02-10 20:29 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: Patrick Cairns, linux-media
On Tue, 2010-02-09 at 10:25 -0500, Devin Heitmueller wrote:
> On Tue, Feb 9, 2010 at 10:19 AM, Patrick Cairns
> <patrick_cairns@yahoo.com> wrote:
> > 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
>
> Are we sure the zl10353 is being reset at all?
Devin,
I know for a fact it is not.
> I've seen cases before
> where the zl10353 can hang the entire i2c bus ( in particular with the
> i2c_gate_ctrl issue), and the only path to recovery is strobing the
> chip reset. It's possible that the GPIO for resetting the zl10353 is
> just *wrong* because somebody copied it from some other board profile,
> and the chip is never being reset.
I have no information of the GPIO line that would be used to reset the
ZL10353. We can narrow the field with some differential analysis.
Patrick,
For every LeadTek 3100 H you have, could you, as root, run
# v4l2-dbg -d /dev/videoN -c host0 -g 0x2c72010
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x02c72010 = 96ff13h (9895699d 00000000 10010110 11111111 00010011b)
And record the register value and whether or not the card initialized
DVB properly or had the error.
This register reads the GPIO line levels. By comparing the differences
between cards after modprobe, we can figure out the set of GPIO lines
that likely could be the reset for the ZL10353 on this board. A GPIO
line that is "low", is a candidate for one that is holding a ZL10353 in
reset on a non-working board.
You could also use, as root:
# cx18-ctl -d /dev/videoN --list-gpio
GPIO in: 0x96ff13
GPIO dir: 0xcffe
GPIO out: 0x3001
which is a little more user friendly.
It would be better to log out the contents of this register immediately
after the zl10353_attach fails in cx18-dvb.c, but we'll hopefully get
close enough without doing that.
Regards,
Andy
> Oh, on an unrelated note, I believe the required xc3028 reset strobe
> time is supposed to be 10ms, but I would have to double check the docs
> to confirm.
>
> Devin
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-10 20:29 ` Andy Walls
@ 2010-02-11 3:31 ` Andy Walls
0 siblings, 0 replies; 8+ messages in thread
From: Andy Walls @ 2010-02-11 3:31 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: Patrick Cairns, linux-media
On Wed, 2010-02-10 at 15:29 -0500, Andy Walls wrote:
> On Tue, 2010-02-09 at 10:25 -0500, Devin Heitmueller wrote:
> >
> > Are we sure the zl10353 is being reset at all?
>
> Devin,
>
> I know for a fact it is not.
>
>
> > I've seen cases before
> > where the zl10353 can hang the entire i2c bus ( in particular with the
> > i2c_gate_ctrl issue), and the only path to recovery is strobing the
> > chip reset. It's possible that the GPIO for resetting the zl10353 is
> > just *wrong* because somebody copied it from some other board profile,
> > and the chip is never being reset.
>
> I have no information of the GPIO line that would be used to reset the
> ZL10353. We can narrow the field with some differential analysis.
>
> Patrick,
>
> For every LeadTek 3100 H you have, could you, as root, run
>
> # v4l2-dbg -d /dev/videoN -c host0 -g 0x2c72010
> ioctl: VIDIOC_DBG_G_REGISTER
> Register 0x02c72010 = 96ff13h (9895699d 00000000 10010110 11111111 00010011b)
>
> And record the register value and whether or not the card initialized
> DVB properly or had the error.
Patrick,
Bah, what was I thinking? You can only record the GPIO levels of cards
that initialize properly with that command. Of all the working cards,
all the GPIO "1" bits that line up between all the cards are the likely
candidates for the ZL10353 reset line.
Regards,
Andy
> It would be better to log out the contents of this register immediately
> after the zl10353_attach fails in cx18-dvb.c, but we'll hopefully get
> close enough without doing that.
>
> Regards,
> Andy
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-09 15:19 Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6) Patrick Cairns
2010-02-09 15:25 ` Devin Heitmueller
@ 2010-02-13 23:28 ` Andy Walls
2010-02-15 20:23 ` Patrick Cairns
1 sibling, 1 reply; 8+ messages in thread
From: Andy Walls @ 2010-02-13 23:28 UTC (permalink / raw)
To: Patrick Cairns; +Cc: linux-media
On Tue, 2010-02-09 at 07:19 -0800, Patrick Cairns wrote:
> > On Tue, 2010-02-09 at 03:35 -0800, Patrick Cairns wrote:
> > > 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:-
> > >
> > 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.
> > > 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.
Patrick,
Can you test the patch below? It will reset the XC3028 before the I2C
bus is first used, and it will try to reset the ZL10353 before the I2C
bus is first used.
You'll need to recompile and test until you find the GPIO line that
appears to reset the ZL10353.
#define DVR3100_ZL10353_RESET_GPIO (1 << 8)
^
|
Change this number
Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0.
If that doesn't work then try them again, but change more of the patch
to assume an active high reset for the ZL10353 GPIO line instead of
active low.
There is also an W83601 chip connected to this I2C bus along with the
XC3028 and ZL10353, but hopefully we won't have to worry about resetting
that too.
Please let me know if you find a GPIO pin that reliably has all your
cards working upon modprobe. You should *not* need to cycle power
between each test.
Regards,
Andy
diff -r 14021dfc00f3 linux/drivers/media/video/cx18/cx18-cards.c
--- a/linux/drivers/media/video/cx18/cx18-cards.c Thu Feb 11 23:11:30 2010 -0200
+++ b/linux/drivers/media/video/cx18/cx18-cards.c Sat Feb 13 18:14:32 2010 -0500
@@ -452,10 +452,34 @@
.tune_lane = 0,
.initial_emrs = 0x2,
},
- .gpio_init.initial_value = 0x6,
- .gpio_init.direction = 0x7,
- .gpio_audio_input = { .mask = 0x7,
- .tuner = 0x6, .linein = 0x2, .radio = 0x2 },
+
+ /*
+ * GPIOs
+ * 0 0x00000001 Audio/FM related???
+ * 1 0x00000002 XC3028 reset line, active low
+ * 2 0x00000004 Audio input multiplexer: 1 - Tuner, 0 - Line-in
+ */
+#define DVR3100_XC3028_RESET_GPIO (1 << 1)
+
+ /* FIXME - Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0, */
+ /* then try them again using active high for the reset, until found */
+#define DVR3100_ZL10353_RESET_GPIO (1 << 8)
+
+ .gpio_init.direction = 0x5 |
+ DVR3100_XC3028_RESET_GPIO |
+ DVR3100_ZL10353_RESET_GPIO,
+ .gpio_init.initial_value = 0x4 |
+ DVR3100_XC3028_RESET_GPIO |
+ DVR3100_ZL10353_RESET_GPIO,
+ .gpio_audio_input = { .mask = 0x4,
+ .tuner = 0x4, .linein = 0x0, .radio = 0x0 },
+ .gpio_i2c_slave_reset = {
+ .active_hi_mask = 0x0,
+ .active_lo_mask = DVR3100_XC3028_RESET_GPIO |
+ DVR3100_ZL10353_RESET_GPIO,
+ .msecs_asserted = 50, /* ZL10353 requires 50 ms */
+ .msecs_recovery = 50, /* A guess */
+ },
.xceive_pin = 1,
.pci_list = cx18_pci_leadtek_dvr3100h,
.i2c = &cx18_i2c_std,
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-13 23:28 ` Andy Walls
@ 2010-02-15 20:23 ` Patrick Cairns
0 siblings, 0 replies; 8+ messages in thread
From: Patrick Cairns @ 2010-02-15 20:23 UTC (permalink / raw)
To: Andy Walls; +Cc: linux-media
Thanks!
That patch, unchanged is consistently successful in addressing the Zarlink initialisation error for me.
It also eliminates a no doubt related problem in the lack of detection of some of the Xceive tuners, a problem I had previously overlooked for some reason and later discovered when I wanted to see if analogue tuning worked. detail: i2c_core:i2c_new_probed_device would fairly consistently fail to find/probe some of the tuners such that 'XX-0061: chip found @ 0xc2 (cx18 i2c driver #X-1)' logs would only appear against roughly half of my cards - a much more obvious problem than the one I originally reported!
Briefly I patched my build to ignore the Zarlink frontend initialisation error and allow the cx18 to proceed to register the v4l device and this helped me meet my main composite video capture project requirement - this is now unnecessary.
I'll be testing over the next few days and report anything unexpected / of interested.
Cheers
Patrick
----- Original Message ----
> From: Andy Walls <awalls@radix.net>
> To: Patrick Cairns <patrick_cairns@yahoo.com>
> Cc: linux-media@vger.kernel.org
> Sent: Sat, 13 February, 2010 23:28:59
> Subject: Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
>
> On Tue, 2010-02-09 at 07:19 -0800, Patrick Cairns wrote:
> > > On Tue, 2010-02-09 at 03:35 -0800, Patrick Cairns wrote:
>
> > > > 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:-
> > > >
>
>
> > > 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.
>
> > > > 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.
>
>
> Patrick,
>
> Can you test the patch below? It will reset the XC3028 before the I2C
> bus is first used, and it will try to reset the ZL10353 before the I2C
> bus is first used.
>
> You'll need to recompile and test until you find the GPIO line that
> appears to reset the ZL10353.
>
> #define DVR3100_ZL10353_RESET_GPIO (1 << 8)
> ^
> |
> Change this number
>
> Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0.
> If that doesn't work then try them again, but change more of the patch
> to assume an active high reset for the ZL10353 GPIO line instead of
> active low.
>
>
> There is also an W83601 chip connected to this I2C bus along with the
> XC3028 and ZL10353, but hopefully we won't have to worry about resetting
> that too.
>
> Please let me know if you find a GPIO pin that reliably has all your
> cards working upon modprobe. You should *not* need to cycle power
> between each test.
>
> Regards,
> Andy
>
> diff -r 14021dfc00f3 linux/drivers/media/video/cx18/cx18-cards.c
> --- a/linux/drivers/media/video/cx18/cx18-cards.c Thu Feb 11 23:11:30 2010
> -0200
> +++ b/linux/drivers/media/video/cx18/cx18-cards.c Sat Feb 13 18:14:32 2010
> -0500
> @@ -452,10 +452,34 @@
> .tune_lane = 0,
> .initial_emrs = 0x2,
> },
> - .gpio_init.initial_value = 0x6,
> - .gpio_init.direction = 0x7,
> - .gpio_audio_input = { .mask = 0x7,
> - .tuner = 0x6, .linein = 0x2, .radio = 0x2 },
> +
> + /*
> + * GPIOs
> + * 0 0x00000001 Audio/FM related???
> + * 1 0x00000002 XC3028 reset line, active low
> + * 2 0x00000004 Audio input multiplexer: 1 - Tuner, 0 - Line-in
> + */
> +#define DVR3100_XC3028_RESET_GPIO (1 << 1)
> +
> + /* FIXME - Try GPIO pins 8-15 first, then 3-7, then 16-31, then 0, */
> + /* then try them again using active high for the reset, until found */
> +#define DVR3100_ZL10353_RESET_GPIO (1 << 8)
> +
> + .gpio_init.direction = 0x5 |
> + DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> + .gpio_init.initial_value = 0x4 |
> + DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> + .gpio_audio_input = { .mask = 0x4,
> + .tuner = 0x4, .linein = 0x0, .radio = 0x0 },
> + .gpio_i2c_slave_reset = {
> + .active_hi_mask = 0x0,
> + .active_lo_mask = DVR3100_XC3028_RESET_GPIO |
> + DVR3100_ZL10353_RESET_GPIO,
> + .msecs_asserted = 50, /* ZL10353 requires 50 ms */
> + .msecs_recovery = 50, /* A guess */
> + },
> .xceive_pin = 1,
> .pci_list = cx18_pci_leadtek_dvr3100h,
> .i2c = &cx18_i2c_std,
^ permalink raw reply [flat|nested] 8+ messages in thread
* Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
@ 2010-02-09 11:35 Patrick Cairns
2010-02-09 13:05 ` Andy Walls
0 siblings, 1 reply; 8+ messages in thread
From: Patrick Cairns @ 2010-02-09 11:35 UTC (permalink / raw)
To: linux-media
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)
cx18-10: frontend initialization failed
cx18-10: DVB failed to register
cx18-10: Registered device radio10 for encoder radio
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
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.
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.
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6)
2010-02-09 11:35 Patrick Cairns
@ 2010-02-09 13:05 ` Andy Walls
0 siblings, 0 replies; 8+ messages in thread
From: Andy Walls @ 2010-02-09 13:05 UTC (permalink / raw)
To: Patrick Cairns; +Cc: linux-media
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.
> 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'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?
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-02-15 20:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-09 15:19 Leadtek WinFast DVR3100 H zl10353_read_register: readreg error (reg=127, ret==-6) Patrick Cairns
2010-02-09 15:25 ` Devin Heitmueller
2010-02-10 20:29 ` Andy Walls
2010-02-11 3:31 ` Andy Walls
2010-02-13 23:28 ` Andy Walls
2010-02-15 20:23 ` Patrick Cairns
-- strict thread matches above, loose matches on Subject: below --
2010-02-09 11:35 Patrick Cairns
2010-02-09 13:05 ` Andy Walls
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox