On 11/13/2011 03:53 AM, Antti Palosaari wrote:
On 11/12/2011 06:59 PM, Antti Palosaari wrote:
I fixed that I2C failing, simply blocking problematic demod callbacks
that only other demod can access at once. Basically problem is that
AF9015 FW don't like to get interrupted for I2C access in certain cases.
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/af9015
I haven't looked stream corruptions and I will not even look, since
those not happening much my hw. I think your fix is based the fact you
forced PID-filter always on. Could you remove all the other changes you
did and force it using dvb-usb orce_pid_filter_usage param to see if
thats really the only only problem? And also testing using max packet
sizes could be interesting to see.
I think I have now found the problem. It seems happen when you watch FE0
and then do some tuning using other FE1. If you just watch both FEs same
time it works rather nicely. That's why I haven't seen that earlier.
Very good way to corruptions is to stream FE0 and then start tuning in
loop through some channels, especially there is channels having no
signal at all.
I just tested you patch series and result was bad. A lot of corruptions.
I was using dual device having MXL5007T tuner.
As I found out how to reproduce errors I did some small test and find
out problem seem to be I2C traffic from 2nd tuner and demod. When you do
some tuning for 2nd FE there is a lot I2C traffic all the time, which I
think overloads AF9015 and couses stream corruption. Disabling all
statistics and returning all the time HAS_LOCK for fe0 and NO LOCK for
FE without any I2C traffic seems to help a lot.
So what's the source of problematic I2C traffic
1) demod status/statistic reading (that have been always optimized by
limiting queries using jiffies)
2) set_frontend()
3) set_params()
I have MXL5007T and MXL5005S. If you look sniffs from windows those
tuner drivers are optimized I2C traffic something like "one go". Linux
drivers generate huge amount of register access because they don't
support writing multiple regs as one go. This leads very bad performance
as a I2C I/O combined to fact I2C-gate open/close is bit field -
changing one bit takes 2 USB messages. So every single tuner register
change generates 2xmsg for gate open, 1xmsg for tuner reg write, 2xmsg
for gate close = 5 messages, where is 4 msg wasted for only I2C gate.
After all, it may generate something ~10-50 times more I/O than Windows
driver.
* I think it is maybe good idea to implement multireg access like
Windows to these tuner drivers first.
* cache gate-control register value inside driver
* program only demod register needed. eg. BW is not changed no need to
program those registers. same for IF frequency. see cxd2820r I did that
* reduce satistics polling. maybe start timer that polls statistics once
per 2 sec or so and return those from cache
regards
Antti
--
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
