Henrik Sj?berg wrote: > Hi, > > After some testing I have made the following discoveries: > > * My card is identified as DTT-CI by dst_get_device_id Can you please tell me what model your card is VP-XXXX ? > * The problems from dmesg doesn't seem to be a timeout. If I read 10 > bytes from the answer from the tuning string instead of 8 (FIXED_COMM) > I get a complete message with a correct checksum in the end. However, This means your tuner has TS=204 > even though the tuning seems to go ok, dst_get_signal returns returns > the string '0x0 0x0 0x0 0x0 0x0 0x2 0xff 0xff' which is not > appreciated by the driver. Let me get back, i will check this up. > * So, reading 10 bytes instead of 8 looks a bit like a card with > DST_TYPE_HAS_NEWTUNE. So, I tried setting DST_TYPE_HAS_NEWTUNE. This > however, gave another problem. Since the request string for frequency > tuning changed, so did the answer. An answer that the driver > interpreted as an indication that the tuning failed. Looks like that. There are some old DTT cards that have TS=204, rather than TS=188. > > Can anyone with more experience of the drivers draw any conclusions > from the logs below? > > I'm a bit curious of the messages sent to the card. > 00 06 00 00 00 00 00 fa is an identification reqeust > 00 05 00 00 00 00 00 fb is a signel request > so, the second(and first?) byte(s) seem to be some kind of primitive > id. However, this is different when setting the frequency. For non > NEWTUNE card f1 f2 f3 00 bw 00 iv ea (fx=frequency, bw=bandwith, > iv=inversion) is used and for NEWTUNE cards, the same, but with a two > byte header is used. These two bytes are 09 00, which could be > primitive id, if it is two bytes. > > How have you deduced the different messages? By trial and error, by > debugging the windows driver or by some other mean? > > Ok, now finally to the two logs: > > Reading 10 bytes instead of 8 in dst_get_tuna: > ============================================== > May 14 09:56:35 thay kernel: Set Frequency = [522000000] > May 14 09:56:35 thay kernel: dst_write_tuna: type_flags 0x52 > May 14 09:56:35 thay kernel: dst_comm_init: Initializing DST.. > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[ffffffff], > enbb=[0001], outhigh=[0000] > May 14 09:56:35 thay kernel: rdc_reset_state: Resetting state machine > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[0002], enbb=[0002], > outhigh=[0000] > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[0002], enbb=[0002], > outhigh=[0002] > May 14 09:56:35 thay kernel: write_dst writing 07 f7 10 00 08 00 00 ea > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[ffffffff], > enbb=[0000], outhigh=[0000] > May 14 09:56:35 thay kernel: read_dst reply is 0xff > May 14 09:56:35 thay kernel: dst_wait_dst_ready: dst wait ready after > 1 > May 14 09:56:35 thay kernel: read_dst reply is 0x9 > May 14 09:56:35 thay kernel: 0xc1 0x11 0xbd 0x0 0x26 0x0 0x0 0x0 0x42 > May 14 09:56:35 thay kernel: dst_comm_init: Initializing DST.. > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[ffffffff], > enbb=[0001], outhigh=[0000] > May 14 09:56:35 thay kernel: rdc_reset_state: Resetting state machine > May 14 09:56:35 thay kernel: dst_gpio_outb: mask=[0002], enbb=[0002], > outhigh=[0000] > May 14 09:56:36 thay kernel: dst_gpio_outb: mask=[0002], enbb=[0002], > outhigh=[0002] > May 14 09:56:36 thay kernel: write_dst writing 00 05 00 00 00 00 00 fb > May 14 09:56:36 thay kernel: dst_gpio_outb: mask=[ffffffff], > enbb=[0000], outhigh=[0000] > May 14 09:56:36 thay kernel: read_dst reply is 0xff > May 14 09:56:36 thay kernel: dst_wait_dst_ready: dst wait ready after > 1 > May 14 09:56:36 thay kernel: read_dst reply is 0x0 > May 14 09:56:36 thay kernel: 0x0 0x0 0x0 0x0 0x2 0xff 0xff > The logs looks quite normal .. Manu
