Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
I think I've isolated the significant part of the demod register setup. Discarding the reads and sorting them in address order, I see ANTTI DVBSKY DIFFER? === === === demod_write(22, [ac]) demod_write(22, [ac]) no demod_write(24, [5c]) demod_write(24, [5c]) no demod_write(25, [8a]) YES demod_write(29, [80]) demod_write(29, [80]) no demod_write(30, [08]) demod_write(30, [08]) no demod_write(33, [00]) YES demod_write(4d, [91]) demod_write(4d, [91]) no demod_write(56, [00]) YES demod_write(61, [5549]) demod_write(61, [55]) no demod_write(62, [49]) no demod_write(76, [38]) YES demod_write(c3, [08]) demod_write(c3, [08]) no demod_write(c4, [08]) demod_write(c4, [08]) no demod_write(c7, [00]) demod_write(c7, [00]) no demod_write(c8, [06]) demod_write(c8, [06]) no demod_write(ea, [ff]) demod_write(ea, [ff]) no demod_write(fd, [46]) demod_write(fd, [06]) YES demod_write(fe, [6f]) demod_write(fe, [6f]) no David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 13:33, David Howells wrote: I think I've isolated the significant part of the demod register setup. Discarding the reads and sorting them in address order, I see ANTTI DVBSKY DIFFER? === === === demod_write(22, [ac]) demod_write(22, [ac]) no demod_write(24, [5c]) demod_write(24, [5c]) no demod_write(25, [8a]) YES seems to be on init table demod_write(29, [80]) demod_write(29, [80]) no demod_write(30, [08]) demod_write(30, [08]) no demod_write(33, [00]) YES That is config option already. Did you set value? If yes, then there is driver bug. If not, then add value. demod_write(4d, [91]) demod_write(4d, [91]) no demod_write(56, [00]) YES driver bug demod_write(61, [5549]) demod_write(61, [55]) no demod_write(62, [49]) no demod_write(76, [38]) YES on init table demod_write(c3, [08]) demod_write(c3, [08]) no demod_write(c4, [08]) demod_write(c4, [08]) no demod_write(c7, [00]) demod_write(c7, [00]) no demod_write(c8, [06]) demod_write(c8, [06]) no demod_write(ea, [ff]) demod_write(ea, [ff]) no demod_write(fd, [46]) demod_write(fd, [06]) YES driver bug demod_write(fe, [6f]) demod_write(fe, [6f]) no Two clear driver bugs, 1 case unclear and the rest should be programmed earlier. So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, 0xfd=0x46 and make test. Do that same to find out all buggy registers until it performs as it should. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari cr...@iki.fi wrote: demod_write(33, [00]) YES That is config option already. Did you set value? If yes, then there is driver bug. If not, then add value. But you don't give me the option of _not_ setting it. The dvbsky driver sets it to 0x35 in its init_tab[] - as does yours - and then leaves it alone. demod_write(76, [38]) YES on init table Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, 0xfd=0x46 and make test. Do that same to find out all buggy registers until it performs as it should. I've made my version of your driver now set up the demod regs as per the dvbsky driver for: S 11919000 V 2750 3/4 but: ./scan-s2/scan-s2 -a1 ./e.1 /tmp/s -O S9.0E -D S2 still doesn't work for your driver, despite two goes at tuning. I guess I need to check the tuner writes too. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On Fri, Nov 15, 2013 at 8:32 AM, David Howells dhowe...@redhat.com wrote: Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. Check your GPIO config for the specific board in the cx23885 driver. Registers unexpectedly resetting to their default value between tunes could very well be because your GPIO setup is incorrect and the demodulator chip's reset line is being strobed between tuning requests. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 15:32, David Howells wrote: Antti Palosaari cr...@iki.fi wrote: demod_write(33, [00]) YES That is config option already. Did you set value? If yes, then there is driver bug. If not, then add value. But you don't give me the option of _not_ setting it. The dvbsky driver sets it to 0x35 in its init_tab[] - as does yours - and then leaves it alone. So what? Do you understand meaning of init tables? If you look those demod drivers about everyone has init tables and it is used just to set some reasonable default values to registers. After that you could change those or leave as is, it is just driver logic. Just set correct value there and it should be OK. + .agc = 0x99, demod_write(76, [38]) YES on init table Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. It is programmed conditionally to avoid I/O. Loading logic is simply and relies to S/S2/sleep mode change. If there is bug then it should be fixed, but I suspect it is just OK as my device is working. If that logic is broken then result is likely very dramatic - you will be able to view only DVB-S or DVB-S2 channels. So hard code those bugs, if you already didn't, 0x33=0x99, 0x56=0x00, 0xfd=0x46 and make test. Do that same to find out all buggy registers until it performs as it should. I've made my version of your driver now set up the demod regs as per the dvbsky driver for: S 11919000 V 2750 3/4 but: ./scan-s2/scan-s2 -a1 ./e.1 /tmp/s -O S9.0E -D S2 still doesn't work for your driver, despite two goes at tuning. I guess I need to check the tuner writes too. These bugs sounds more like a demod bugs. Have you tried simple tune using szap/s2-szap to single channel? Don't try scan before it works for single S and S2 channel using zap. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
David Howells dhowe...@redhat.com wrote: I guess I need to check the tuner writes too. From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
On 15.11.2013 15:56, David Howells wrote: David Howells dhowe...@redhat.com wrote: I guess I need to check the tuner writes too. From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? ... and the result is same, reg 10 will be 0a and reg 11 40. It is register write using register address auto-increment. The later one is I/O optimized. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
David Howells dhowe...@redhat.com wrote: I guess I need to check the tuner writes too. From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? Setting it to 0x0a in the driver doesn't seem to help. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari cr...@iki.fi wrote: But you don't give me the option of _not_ setting it. The dvbsky driver sets it to 0x35 in its init_tab[] - as does yours - and then leaves it alone. So what? Do you understand meaning of init tables? Yes. You misunderstand what I'm saying. You unconditionally write cfg-agc to port 0x33 in m88ds3103_set_frontend() after loading the init tables. Why do you need to do that at all if the default is fine? You don't give me the option of saying that I want to stick with the default and not change it. Just set correct value there and it should be OK. + .agc = 0x99, Why is 0x99 correct? The default is 0x35 and the dvbsky driver does not alter it from that. Btw, setting it to 0x99 has no obvious effect over leaving it as the default. Whilst that may be so, something clears it between one call to m88ds3103_set_frontend() and the next, so you probably need to unconditionally reload the program init table. It is programmed conditionally to avoid I/O. Obviously. Nonetheless, register 0x76 seems to change its value between passes through your code without you touching it inbetween:-/ David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Antti Palosaari cr...@iki.fi wrote: I guess I need to check the tuner writes too. From dvbsky: TUNER_write(10, [0a]) TUNER_write(11, [40]) and from your driver: TUNER_write(10, [0b40]) That would appear to be some sort of tuner frequency setting? ... and the result is same, reg 10 will be 0a and reg 11 40. It is register write using register address auto-increment. The later one is I/O optimized. Yes, I understand that. However, reg 10 is set to 0a in one driver and 0b in the other. David -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
Hello
You have to identify situation where it does not work, optimally single
known channel. Then switch to working driver and tune that same channel
and take sniffs. Then generate code from sniffs, copy paste that to
non-working driver until it starts working. Then it is quite trivial to
find out by error and trial tests binary search where the problematic
register is.
Here is some tips.
http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
Hacking script I used is attached, just for the example.
regards
Antti
On 15.11.2013 01:35, David Howells wrote:
Here are four logs from doing:
scandvb -a1 ./e.1
where the contents of file e.1 are:
S 11919000 V 2750 3/4
which is probing a region on the Eutelsat-9A satellite broadcast.
I inserted:
diff -uNr linux-3.11.7-300.dvbsky_4.fc20.x86_64/drivers/i2c/i2c-core.c
i2c-monitor/drivers/i2c/i2c-core.c
--- i2c-monitor/drivers/i2c/i2c-core.c 2013-09-02 21:46:10.0
+0100
+++ linux-3.11.7-300.dvbsky_4.fc20.x86_64/drivers/i2c/i2c-core.c
2013-11-14 22:11:08.757282401 +
@@ -1491,6 +1491,16 @@
unsigned long orig_jiffies;
int ret, try;
+ for (ret = 0; ret num; ret++) {
+ if (msgs[ret].flags I2C_M_RD)
+ pr_notice(I2C %s: RD %02x %u\n,
+ adap-name, msgs[ret].addr,
msgs[ret].len);
+ else
+ pr_notice(I2C %s: WR %02x %u [%*phN]\n,
+ adap-name, msgs[ret].addr,
msgs[ret].len,
+ msgs[ret].len, msgs[ret].buf);
+ }
+
/* Retry automatically on arbitration loss */
orig_jiffies = jiffies;
for (ret = 0, try = 0; try = adap-retries; try++) {
into the kernel to generate these logs.
The four logs are:
(1) DVBSky's megapatch: I2C traffic generated by cx23885 module initialisation
and probing.
(2) DVBSky's megapatch: I2C traffic generated by the aforementioned scandvb
command.
(3) Antti's drivers plus my S952 glue: I2C traffic generated by cx23885
module initialisation and probing.
(4) Antti's drivers plus my S952 glue: I2C traffic generated by the
aforementioned scandvb command.
The scandvb command with the DVBSky megapatch gave:
dumping lists (25 services)
Italy Service:11919:v:0:27500:2003:3003:3
Karusel int:11919:v:0:27500:2004:3004:4
SVT WORLD:11919:v:0:27500:2008:3008:8
...
and was very consistent.
Antti's patch gave:
dumping lists (22 services)
[0001]:11919:v:0:27500:0:0:1
[0003]:11919:v:0:27500:0:0:3
[000d]:11919:v:0:27500:0:0:13
...
and sometimes:
dumping lists (0 services)
and once:
dumping lists (32 services)
[f714]:11919:v:0:27500:0:0:63252
[e38b]:11919:v:0:27500:0:0:58251
[b7ba]:11919:v:0:27500:0:0:47034
...
David
--
http://palosaari.fi/
#!/usr/bin/env python
# Copyright (C) 2013 Antti Palosaari cr...@iki.fi
# Usage:
import os
import sys
import re
import struct
import string
fread = file(sys.argv[1], 'r' )
def get_hex_string(ele, start, length):
string = ''
for i in range(length):
string = string + '\\x' + ele[start + i]
string = string + ''
return string
for line in fread:
line = line.strip();
ele = re.split(' ', line)
print '// ' + line
#025099: OUT: 00 ms 009725 ms 40 02 00 00 c0 00 02 00 00 03
#025522: OUT: 00 ms 024417 ms 40 02 00 00 d0 00 02 00 03 11
if (len(ele) 17 and ele[15] == '' and ele[8] == '02'):
length = int(ele[13], 16) - 1
if (ele[11] == 'c0'):
print 'ret = m88ts2022_wr_regs(priv, 0x' + ele[17] + ', ' + \
get_hex_string(ele, 18, length) + ', ' + str(length) + '); // generated'
elif (ele[11] == 'd0'):
print 'ret = m88ds3103_wr_regs(priv, 0x' + ele[17] + ', ' + \
get_hex_string(ele, 18, length) + ', ' + str(length) + '); // generated'
fread.close()
Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
David Howells dhowe...@redhat.com wrote:
Here are four logs from doing:
scandvb -a1 ./e.1
where the contents of file e.1 are:
S 11919000 V 2750 3/4
which is probing a region on the Eutelsat-9A satellite broadcast.
Here's a script for turning the logs from:
I2C cx23885[0]: RD 60 1
I2C m88ds3103: WR 60 2 [0003]
I2C cx23885[0]: WR 68 2 [0311]
I2C cx23885[0]: WR 60 2 [0003]
I2C m88ds3103: WR 60 1 [00]
into something that looks like:
demod_read(23)
demod_write(23, [1f])
TUNER_read(00)
TUNER_write(00, [03])
TUNER_read(00)
and checks for and hides the tuner gate opening commands to the ds3103.
David
---
#!/usr/bin/perl -w
use strict;
my $last_adap = 0;
my $last_dev = 0;
my $last_reg = 0;
my $tuner_gate = 0;
while () {
chomp;
if (/^I2C ([^:]*): RD ([0-9A-Fa-f]{2}) ([0-9]{1,2})/) {
my $adap = $1;
my $dev = $2;
my $n = $3;
die if ($dev ne 6b $dev ne $last_dev);
if ($dev eq 68) {
# Demodulator register
die if ($tuner_gate);
print demod_read(, $last_reg, )\n;
} elsif ($dev eq 60) {
# Tuner register
# Ignore stuff on the internal tuner-demod bus in Antti's driver
next if ($adap eq m88ds3103);
die if (!$tuner_gate);
$tuner_gate = 0;
print TUNER_read(, $last_reg, )\n;
} else {
print RD , $adap, , $dev, , $n, \n;
}
} elsif (/^I2C ([^:]*): WR ([0-9A-Fa-f]{2}) ([0-9]{1,2})
[[]([0-9A-Fa-f]{2,})[]]/) {
my $adap = $1;
my $dev = $2;
my $n = $3;
my $data = $4;
$last_adap = $adap;
$last_dev = $dev;
die if (int($n) = 0);
die if (length($data) != int($n) * 2);
if ($dev eq 68) {
# Demodulator register
die if ($tuner_gate);
my $reg = substr($data, 0, 2);
if ($n == 2 $data eq 0311) {
$tuner_gate = 1;
} elsif ($n 1) {
print demod_write(, $reg, , [, substr($data, 2), ])\n;
$last_dev = 0;
} else {
$last_reg = $reg;
}
} elsif ($dev eq 60) {
# Tuner register
# Ignore stuff on the internal tuner-demod bus in Antti's driver
next if ($adap eq m88ds3103);
die if (!$tuner_gate);
my $reg = substr($data, 0, 2);
if ($n 1) {
print TUNER_write(, $reg, , [, substr($data, 2), ])\n;
$last_dev = 0;
$tuner_gate = 0;
} else {
$last_reg = $reg;
}
} else {
print WR , $1, , $2, , $3, , $4, \n;
}
} else {
print;
print \n;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
