Hi Antti, I have the feeling, that you spending your time for nothing - and that this is my fault. Have you ever tried to use the Nova-T 500 in Windows with the same intensity as it is done by MythTV and/or VDR (in EPG-scan and channel-scan mode)? I think you will see the problem also - even though not 100% sure due to differences in the USB-transfer-stack. However debugging the usblog to get i2c-messages is not really useful, because the demod-driver for LinuxTV and Windows is coming from the exact same source. On the other hand I can confirm that there are some problem with this device when it is really stressed. Strangly enough it is only the case with exactly this device (in combination with the MT2060-tuner). Newer Dual devices (like from Pinnacle) haven't got the problems. Was the disconnect still related to a "babble" using the bigger buffers? If so, try to increase the buffer again to 64KB. Or try to reduce it to 1KB (or 512Byte) and at the same increase the number of URBs to 50. Patrick. On Sun, 11 Mar 2007, Antti P Miettinen wrote: > Antti P Miettinen <ananaza@xxxxxx> writes: > > I'll try deciphering the log more later. > > OK, here's a little snippet more. > > After the GPIO settings there seems to be some I2C traffic. But again > not exactly the same what the linux driver would be doing. The first > packet is a control packet: > > c0 02 1d 02 01 84 02 00 > > which translates to > > bRequestType = 0xc0 (dir: device-to-host, type: vendor, recipient: device) > bRequest = 0x02 (REQUEST_I2C_READ) > wValue = 0x021d > wIndex = 0x8401 > wLength = 2 > > This almost matches I2C read but not quite. As far as I understand the > dib3000mc.c and dib0700_core.c the wIndex value should always be zero > for I2C reads. The dib0700_ctrl_rd sets the index from tx buffer if > there is enough data but dib3000mc_read_word() seems to set up two > separate i2c messages, one for write, one for read. So would this be a > combined one message for those two read/write messages? And the > address would be 28 and the reg would be 1025? Anyway - there's no > answer data from the device to this. > > The next setup packet is similar: > > c0 02 19 02 01 84 02 00 > > So here the address would be 24. To this there is answer data > > 01 b3 > > which seems to be the value agains which we check in > dib3000mc_identify(). But as far as I can tell > dib3000mc_i2c_enumeration() requires matching aswer from all addresses > 20, 22, 24 and 26? And also either 0x3001 or 0x3002 for reg 1026. > > Anyway - then there are three writes, if I'm interpreting > correctly: > - addr=24, reg=1040, val=1 > - addr=24, reg=244, val=1 > - addr=24, reg=1024, val=225 > > Then again similar reads to the above, no answer data from > address 26, 0x01b3 from 24. Then three writes: > - addr=24, reg=1040, val=1 > - addr=24, reg=244, val=2048 > - addr=24, reg=1024, val=209 > > Then a read (addr=28, reg=1024, answer 0x00e1), then write (addr=28, > reg=1024, val=227). Then the log parsed by parser.pl shows something > weird. Hmm.. need to check agains the original log.. > > -- > http://www.iki.fi/~ananaza/ > > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
