* I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
@ 2013-11-14 23:35 David Howells
2013-11-14 23:48 ` Antti Palosaari
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: David Howells @ 2013-11-14 23:35 UTC (permalink / raw)
To: Antti Palosaari, Mauro Carvalho Chehab
Cc: dhowells, linux-media, Jarkko Korpi
[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]
Here are four logs from doing:
scandvb -a1 ./e.1
where the contents of file e.1 are:
S 11919000 V 27500000 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.000000000 +0100
+++ linux-3.11.7-300.dvbsky_4.fc20.x86_64/drivers/i2c/i2c-core.c 2013-11-14 22:11:08.757282401 +0000
@@ -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
[-- Attachment #2: mega-initial-i2c.log.bz2 --]
[-- Type: application/x-bzip2, Size: 23104 bytes --]
[-- Attachment #3: mega-worked-i2c.log.bz2 --]
[-- Type: application/x-bzip2, Size: 659 bytes --]
[-- Attachment #4: antti-initial-i2c.log.bz2 --]
[-- Type: application/x-bzip2, Size: 12633 bytes --]
[-- Attachment #5: antti-worked-i2c.log.bz2 --]
[-- Type: application/x-bzip2, Size: 6420 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-14 23:35 I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver David Howells
@ 2013-11-14 23:48 ` Antti Palosaari
2013-11-15 2:15 ` David Howells
2013-11-15 11:33 ` David Howells
2 siblings, 0 replies; 13+ messages in thread
From: Antti Palosaari @ 2013-11-14 23:48 UTC (permalink / raw)
To: David Howells, Mauro Carvalho Chehab; +Cc: linux-media, Jarkko Korpi
[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]
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 27500000 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.000000000 +0100
> +++ linux-3.11.7-300.dvbsky_4.fc20.x86_64/drivers/i2c/i2c-core.c 2013-11-14 22:11:08.757282401 +0000
> @@ -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/
[-- Attachment #2: em28xx_m88ds3103.py --]
[-- Type: text/x-python, Size: 1095 bytes --]
#!/usr/bin/env python
# Copyright (C) 2013 Antti Palosaari <crope@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: 000000 ms 009725 ms 40 02 00 00 c0 00 02 00 >>> 00 03
#025522: OUT: 000000 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()
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-14 23:35 I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver David Howells
2013-11-14 23:48 ` Antti Palosaari
@ 2013-11-15 2:15 ` David Howells
2013-11-15 11:33 ` David Howells
2 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 2:15 UTC (permalink / raw)
Cc: dhowells, Antti Palosaari, Mauro Carvalho Chehab, linux-media,
Jarkko Korpi
David Howells <dhowells@redhat.com> wrote:
> Here are four logs from doing:
>
> scandvb -a1 ./e.1
>
> where the contents of file e.1 are:
>
> S 11919000 V 27500000 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";
}
}
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-14 23:35 I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver David Howells
2013-11-14 23:48 ` Antti Palosaari
2013-11-15 2:15 ` David Howells
@ 2013-11-15 11:33 ` David Howells
2013-11-15 13:06 ` Antti Palosaari
2 siblings, 1 reply; 13+ messages in thread
From: David Howells @ 2013-11-15 11:33 UTC (permalink / raw)
To: Antti Palosaari, Mauro Carvalho Chehab
Cc: dhowells, linux-media, Jarkko Korpi
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 11:33 ` David Howells
@ 2013-11-15 13:06 ` Antti Palosaari
2013-11-15 13:32 ` David Howells
0 siblings, 1 reply; 13+ messages in thread
From: Antti Palosaari @ 2013-11-15 13:06 UTC (permalink / raw)
To: David Howells, Mauro Carvalho Chehab; +Cc: linux-media, Jarkko Korpi
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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:06 ` Antti Palosaari
@ 2013-11-15 13:32 ` David Howells
2013-11-15 13:36 ` Devin Heitmueller
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 13:32 UTC (permalink / raw)
To: Antti Palosaari
Cc: dhowells, Mauro Carvalho Chehab, linux-media, Jarkko Korpi
Antti Palosaari <crope@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 27500000 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:32 ` David Howells
@ 2013-11-15 13:36 ` Devin Heitmueller
2013-11-15 13:54 ` Antti Palosaari
2013-11-15 13:56 ` David Howells
2 siblings, 0 replies; 13+ messages in thread
From: Devin Heitmueller @ 2013-11-15 13:36 UTC (permalink / raw)
To: David Howells
Cc: Antti Palosaari, Mauro Carvalho Chehab, Linux Media Mailing List,
Jarkko Korpi
On Fri, Nov 15, 2013 at 8:32 AM, David Howells <dhowells@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:32 ` David Howells
2013-11-15 13:36 ` Devin Heitmueller
@ 2013-11-15 13:54 ` Antti Palosaari
2013-11-15 14:17 ` David Howells
2013-11-15 13:56 ` David Howells
2 siblings, 1 reply; 13+ messages in thread
From: Antti Palosaari @ 2013-11-15 13:54 UTC (permalink / raw)
To: David Howells; +Cc: Mauro Carvalho Chehab, linux-media, Jarkko Korpi
On 15.11.2013 15:32, David Howells wrote:
> Antti Palosaari <crope@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 27500000 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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:32 ` David Howells
2013-11-15 13:36 ` Devin Heitmueller
2013-11-15 13:54 ` Antti Palosaari
@ 2013-11-15 13:56 ` David Howells
2013-11-15 13:59 ` Antti Palosaari
2013-11-15 14:01 ` David Howells
2 siblings, 2 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 13:56 UTC (permalink / raw)
To: Antti Palosaari
Cc: dhowells, Mauro Carvalho Chehab, linux-media, Jarkko Korpi
David Howells <dhowells@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:56 ` David Howells
@ 2013-11-15 13:59 ` Antti Palosaari
2013-11-15 14:25 ` David Howells
2013-11-15 14:01 ` David Howells
1 sibling, 1 reply; 13+ messages in thread
From: Antti Palosaari @ 2013-11-15 13:59 UTC (permalink / raw)
To: David Howells; +Cc: Mauro Carvalho Chehab, linux-media, Jarkko Korpi
On 15.11.2013 15:56, David Howells wrote:
> David Howells <dhowells@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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:56 ` David Howells
2013-11-15 13:59 ` Antti Palosaari
@ 2013-11-15 14:01 ` David Howells
1 sibling, 0 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 14:01 UTC (permalink / raw)
To: Antti Palosaari
Cc: dhowells, Mauro Carvalho Chehab, linux-media, Jarkko Korpi
David Howells <dhowells@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:54 ` Antti Palosaari
@ 2013-11-15 14:17 ` David Howells
0 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 14:17 UTC (permalink / raw)
To: Antti Palosaari
Cc: dhowells, Mauro Carvalho Chehab, linux-media, Jarkko Korpi
Antti Palosaari <crope@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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver
2013-11-15 13:59 ` Antti Palosaari
@ 2013-11-15 14:25 ` David Howells
0 siblings, 0 replies; 13+ messages in thread
From: David Howells @ 2013-11-15 14:25 UTC (permalink / raw)
To: Antti Palosaari
Cc: dhowells, Mauro Carvalho Chehab, linux-media, Jarkko Korpi
Antti Palosaari <crope@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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-11-15 14:25 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-14 23:35 I2C transfer logs for Antti's DS3103 driver and DVBSky's DS3103 driver David Howells
2013-11-14 23:48 ` Antti Palosaari
2013-11-15 2:15 ` David Howells
2013-11-15 11:33 ` David Howells
2013-11-15 13:06 ` Antti Palosaari
2013-11-15 13:32 ` David Howells
2013-11-15 13:36 ` Devin Heitmueller
2013-11-15 13:54 ` Antti Palosaari
2013-11-15 14:17 ` David Howells
2013-11-15 13:56 ` David Howells
2013-11-15 13:59 ` Antti Palosaari
2013-11-15 14:25 ` David Howells
2013-11-15 14:01 ` David Howells
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox