You should take sniffs from your device and look values from there in
order to get understanding.
Thats seems to be one thing looked from my old tests:
u8 zl10353_unknown[] = { 0x90, 0x00, 0xff, 0xff, 0x00, 0xff, 0x3f, 0x3f };
IIRC those were related to IF/RF AGC limits. If you fix tuner then you
should fix demod too. Otherwise it will not work properly if at all.
I think changing that one register off by one or two does not have much
effort if all the others are correct. Just for the calibration.
regards
Antti
On 12/21/2011 12:36 PM, Jyrki Kuoppala wrote:
Thanks, apparently you mean the valptr setting if clauses in QT1010_RD
and QT1010_M1 cases, if I understand you correctly you are saying code
should be changed as in the diff below (after my signature).
The change has to with setting reg1f_init_val, reg20_init_val and
reg25_init_val. To match with
http://linuxtv.org/wiki/index.php/Quantek_QT1010 , the registers are 31,
32 and 37 in decimal.
The patch sent by Carlos modifies how register 0x22 (register 34 in
decimal) is set from the frequency. Carlos's patch is based on my patch
which was based on the apparently incorrect (based on Carlos's feedback
to my original patch, but see below, perhaps the assumption wasn't
incorrect after all) assumption of linear relation between frequency and
register 34 equals 0x22 value. So, basically Carlos removed the 0xd1 ->
0xd2 part of my patch.
When following frequency setting from the description at
http://linuxtv.org/wiki/index.php/Quantek_QT1010 , register 34 is set
from freq_slot12 in the following manner:
* if reg5_1 is equal to 0x34
o if freq_slot12 is larger equal to 0xF0
+ if freq_slot12 is less equal to 0xFA
# write freq_slot12 minus 0x20 into freq_slot12
+ else
# write 0xDA into freq_slot12
o else
+ write 0xD0 into freq_slot12
o write freq_slot12 into tmp_var1
* else
o write 0xD0 into tmp_var1
* write tmp_var1 to tuner register 34
That does describe a linear correlation between freq_slot12 value and
what is stored to register 34. 0xf0..0xfa are converted to 0xd0 .. 0xda
which are also the values used in qt1010.c. But I can't find where
freq_slot12 comes from (that's apparently in the incomplete part
ofcalculate_parameter). So it's possible freq_slot12 is converted from
the frequency non-linearly somewhere before it's used to set register
34. The current qt1010.c frequency to register 34 value conversion is
non-linear and looks strange, setting 0xd1 where linearly setting the
value would be 0xd2. But IIRC Carlos reported that changing it to 0xd2
(as in my original proposed patch) breaks some frequencies.
One possibility to try would be to test if the setting of reg 34 indeed
should be linearly derived from frequency, however not 0xd0, 0xd2, 0xd4
etc. as in my original patch but instead try 0xd0, 0xd1, 0xd2, 0xd3 etc:
if (freq < 450000000) rd[15].val = 0xd0; /* 450 MHz */
else if (freq < 466000000) rd[15].val = 0xd1; /* 466 MHz */
else if (freq < 482000000) rd[15].val = 0xd2; /* 482 MHz */
else if (freq < 498000000) rd[15].val = 0xd3; /* 498 MHz */
else if (freq < 514000000) rd[15].val = 0xd4; /* 514 MHz */
else if (freq < 530000000) rd[15].val = 0xd5; /* 530 MHz */
else if (freq < 546000000) rd[15].val = 0xd6; /* 546 MHz */
else if (freq < 562000000) rd[15].val = 0xd7; /* 562 MHz */
else if (freq < 578000000) rd[15].val = 0xd8; /* 578 MHz */
Carlos, can you try this, if this makes all channels work for you?
According to my reasoning, this could be the proper patch, as the 0xd1
-> 0xd2 change in my original patch failed for you. This would fit the
picture if your frequency is between 450 Mhz and 466 Mhz, in which case
my patch changes the correct 0xd1 to the incorrect 0xd2.
If the test succeeds and the relation indeed is linear, instead of the
table we'll the conversion with math, it's of course silly to have a
table for a linear relation.
Going through this makes me wonder if we perhaps have two separate
issues here - one problem with frequency setting experienced by me &
Carlos, and another problem with tuner init & AGC which Antti is
describing. Antti, can you comment if you think this may be the case? Or
is the register 31,32&37 setting somehow related to frequency selection?
Just wondering why the frequency table seems to fix the issue that me &
Carlos and others are seeing, if the problem is somewhere else as Antti
is saying. Two separate issues could explain this.
Antti, any pointers / more info on what's the problem with
drivers/media/dvb/frontends/zl10353.c AGC settings and how to fix those
settings?
Jyrki
diff -ur linux-3.0.3.orig/drivers/media/common/tuners/qt1010.c
linux-3.0.3/drivers/media/common/tuners/qt1010.c
--- linux-3.0.3.orig/drivers/media/common/tuners/qt1010.c
2011-08-17 20:57:16.000000000 +0300
+++ linux-3.0.3/drivers/media/common/tuners/qt1010.c 2011-12-21
10:38:46.089650261 +0200
@@ -371,16 +372,16 @@
i2c_data[i].val);
break;
case QT1010_RD:
- if (i2c_data[i].val == 0x20)
+ if (i2c_data[i].reg == 0x20)
valptr = &priv->reg20_init_val;
else
valptr = &tmpval;
err = qt1010_readreg(priv, i2c_data[i].reg,
valptr);
break;
case QT1010_M1:
- if (i2c_data[i].val == 0x25)
+ if (i2c_data[i].reg == 0x25)
valptr = &priv->reg25_init_val;
- else if (i2c_data[i].val == 0x1f)
+ else if (i2c_data[i].reg == 0x1f)
valptr = &priv->reg1f_init_val;
else
valptr = &tmpval;
21.12.2011 10:19, Antti Palosaari kirjoitti:
Moikka Jyrki & all.
If you look qt1010_init() you can see some registers are stored
wrongly. There is compares that stores register values when .val is
given. As you can see easily, it should store those when .reg is
correct. Store register 0x25 when it is register 0x25 not register
value. That leads calibration wrong => tuner sensitivity is bad.
But if you fix that it will not likely work since ZL10353 demod AGC
settings are not correct. So you should fix it too.
I hope you will fix that, since it is surely 10th time I am explaining
that same story for someone :-(
t. Antti
On 12/21/2011 09:42 AM, Jyrki Kuoppala wrote:
Hi,
To try and shed some more light into the issue, can you describe what
the problem really is and how would we fix the driver correctly? By
"work or not", do you mean the fix works with some devices but not with
some other devices, with some received signal strengths but not some, or
something else? Do you think there's a risk the fix will break
something?
For me, without the fix, some of the major channels from the transmitter
in the second largest city of Finland are missing, in other words the
fix would remove a major showstopper. Based on Carlos's note, the
situation in UK is something similar.
It's of course best to aim for the best possible fix, and if we have
enough information to do that, that's of course preferable over this
one. However, if there isn't enough information, and there's no risk of
the proposed fix breaking something, perhaps this patch should be put in
as an interim fix and add some notes somewhere that a better fix is
preferable.
Jyrki
21.12.2011 09:26, Antti Palosaari kirjoitti:
Hello,
You can try to fix it like that, but it is not proper way. It is kinda
of hack which can just work or not. Proper way is to fix that tuner
driver correctly and if it was used with zl10353 demoed fix that
driver too to support IIRC IF/RF agc settings.
regards
Antti
On 12/20/2011 12:50 PM, Carlos Corbacho wrote:
The patch fixes frequency selection for some UHF frequencies e.g.
channel 32 (562 MHz) on the qt1010 tuner. For those in the UK,
this now means they can tune to the BBC channels (tested on a Compro
Vista T750F).
One example of problem reports of the bug this fixes can be read at
http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb
Based on an original patch by Jyrki Kuoppala<jkp@xxxxxx>
Signed-off-by: Carlos Corbacho<carlos@xxxxxxxxxxxxxxxxxxx>
Cc: Jyrki Kuoppala<jkp@xxxxxx>
Cc: Mauro Carvalho Chehab<mchehab@xxxxxxxxxxxxx>
---
drivers/media/common/tuners/qt1010.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/qt1010.c
b/drivers/media/common/tuners/qt1010.c
index 9f5dba2..8c57d8c 100644
--- a/drivers/media/common/tuners/qt1010.c
+++ b/drivers/media/common/tuners/qt1010.c
@@ -200,7 +200,8 @@ static int qt1010_set_params(struct dvb_frontend
*fe,
if (freq< 450000000) rd[15].val = 0xd0; /* 450 MHz */
else if (freq< 482000000) rd[15].val = 0xd1; /* 482 MHz */
else if (freq< 514000000) rd[15].val = 0xd4; /* 514 MHz */
- else if (freq< 546000000) rd[15].val = 0xd7; /* 546 MHz */
+ else if (freq< 546000000) rd[15].val = 0xd6; /* 546 MHz */
+ else if (freq< 578000000) rd[15].val = 0xd8; /* 578 MHz */
else if (freq< 610000000) rd[15].val = 0xda; /* 610 MHz */
else rd[15].val = 0xd0;
--
To unsubscribe from this list: send the line "unsubscribe
linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
