Hi all,
this week I tried again to solve some remains problems with budget
card sub id 0x1017 TT-budget S-1500 (model ALPS BSBE1) extended
by optional "ci pci board".
all seems to work basically after moving this card under budget-ci
driver, but time to time i have registered groups of errors and
sometime dropouts caused by new locking of tuner. interesting that
these problems not too visible with receiver card working alone,
but appeared after interconnecting one with "ci pci board" by supplied
ribbon cable. but problems not depend on inserting cam on it - problems
stay even with empty ci slot. also really very very rarely had appeared
errors during initialization of module like: can not read from eeprom,
frontend driver not found or lnbp21 not found.
so i start to checking and tracing driver to locate problem, i found that
main source of problem is a bit problematic internal i2c bus on receiver
card which is possibly also directly wired with some chip on ci expansion
board (there are 1x some logical array + some latches around) because
problems seems to observed mainly when ci board electrically connected.
during debugging i found also a two other minor settings which i changed:
I2C BUS RETRIES
---------------
as i found problems starts near loop for end of i2c transfer, in function
"saa7146_i2c_writeout" in file "saa7146_i2c.c" starting from line 221,
this loop VERY often ends with timeout (returns -EIO (-5)) because
stay too long in busy state 0x00000001, unfortunatelly increasing 10ms
"timeout" there do not helps, like was this state not depend on time.
next called "saa7146_i2c_reset" must always need use abort and clear
twice because first attempt only cause status 0x00000042 (bus error
& general error) so second part of reset sequence needed for recover.
of course i has try to change also various other timing variables
include: SAA7146_I2C_TIMEOUT, SAA7146_I2C_RETRIES,
SAA_I2C_SHORT_DELAY, SAA_I2C_DELAY,
SAA7146_I2C_BUS_BIT_RATE_xxx.
interesting that no timing related parameter was noticeable effect.
so i think that on i2c bus is in case connecting ci board some voltage
potencial or resistance problem, not dynamical load (increased inductance
or capacity of extended i2c bus by ci board interconnection).
so i add line in end of retry loop in "saa7146_i2c_writeout" which allows
me later easily logging and later count number of retries from syslog
to exactly count them and compare rates in table which is below. these
typical counts of retries was counted on original unmodified driver
from v4l-dvb, for these board configurations:
- receiver card alone without CI extension board (woCI)
- with CI pci extension connected but empty CI slot (wCI)
- with CI pci extension and cam with crypto card inserted (wCI&CAM&card)
every case counted during more than one hour of receiving dvb-s in vlc
which normaly do about two readings from card (SNR and status) every one
second, results are related to total of 10000 i2c successfully finished
readings:
for success needed
tries woCI wCI wCI&CAM&card note
---------------------------------
1 9041 6833 7256
2 855 2267 1982
3 94 616 557
4 9 189 143
5 1 65 47
6 0 26 12
7 0 2 2
8 0 1 0
9 0 0 0
10 0 0 1
11 0 1 0
12 0 0 0
total finally successed transfers:
10000 10000 10000
note that EVERY started reading was on last successed, but these retries..
:-(
it shows that normally even with virtally reliable working S-1500
without CI extension still occured 11 fully unsuccessfull readings
during a hour, but only because actual limit SAA7146_I2C_RETRIES=3,
in practice it cause in worst case new tuning or similar effect
depend on application, there is every average 10% of chance for
forced i2c reset unfortunatelly, and with ci board a much much
worst 33% :-( which is a bit too.. is it normal??
in worst cases a still successfull reading gots after 11th try,
but must be retry limit high enought !
-> so i recommend to set in file saa7146.h parameter
SAA7146_I2C_RETRIES safely to 15 or even better to 20,
then at least for S-1500 all works reliable, stream alone seems
not to be affected by dose of i2c resets. Only thing I am affraid
now is potentially increased jitter due to delays inserted in reset
code, i dont know rest of code.. - is increased jitter possible?
streem visually seems to be fine and even paranoid vlc input demux
do not reports errors about stange retunings or holes in stream ever more.
there is always better increased jitter than ten seconds hole in stream
as before, before was stream unreliable now is fine, without errors.
maybe should try it somebody else with some other saa7146 card to
compare...
LNBP21 CURRENT LIMIT
--------------------
if piece of lnbp21 set-up code from sirs from technotrend - thanks
Percefal's info:
http://www.linuxtv.org/pipermail/linux-dvb/2006-February/008417.html
are related to this board and we are care about LLC setting, we can follow
also setting of ISEL which is on technotrend's code set to 0 (higher
current limit) - why not to set it same? should be safe...
-> there is currently used ISEL=1 in v4l-dvb for S-1500, as initialised in
lnbp21.h, so best place to override this default is in budget-ci.c line
1079, instead:
if (lnbp21_init(budget_ci->budget.dvb_frontend, &budget_ci->budget.i2c_adap,
LNBP21_LLC, 0)) {
we may set
if (lnbp21_init(budget_ci->budget.dvb_frontend, &budget_ci->budget.i2c_adap,
LNBP21_LLC, LNBP21_ISEL )) {
or, we may force also bits 5 and 7 to 0 as technotrend developers in code
did,
depend on how much we rely on lnbp21.h defaults...:
if (lnbp21_init(budget_ci->budget.dvb_frontend, &budget_ci->budget.i2c_adap,
LNBP21_LLC, LNBP21_PCL | LNBP21_ISEL | LNBP21_TEN )) {
I2C CLOCK RATE
--------------
currently used clock rate for i2c are in 7146 generated by divider from pci
clock,
by rate of 1:120. max clock rate of used i2c ifaces are LNBP21: 400kHz,
SAA7146: 500kHz BSBU1: dont know... so 400kHz is actually upper limit for
me,
in case if slow PC it is just ok because
33MHz/120=275kHz but 66MHz/120=550kHz(!) 100MHz/120=833kHz(!)
133MHz/120=1.1MHz(!)
i dont know how much its a deal on i2c problems but for me seems to be
better
rate 480:
33MHz/480=69kHz but 66MHz/480=138kHz 100MHz/480=208kHz 133MHz/480=277kHz
-> i later also changed in file budget-core.c line
saa7146_i2c_adapter_prepare(dev, &budget->i2c_adap,
SAA7146_I2C_BUS_BIT_RATE_120);
to be hw more safe onto:
saa7146_i2c_adapter_prepare(dev, &budget->i2c_adap,
SAA7146_I2C_BUS_BIT_RATE_480);
all these changes works for me and stream is totally without errors, but now
i am interested on all members opinions, pros or cons of these steps or
other
alternative ideas and solutions to get work this card better and better :-)
especially to cop agains with this i2c problem on card.
Pavel
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
