[PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[Malcolm Priestley]

Here is the lastest patches, for dual tuner and other fixes on the patchwork server.


Malcolm Priestley (7):
  af9015 Slow down download firmware
  af9015 Remove call to get config from probe.
  af9015/af9013 full pid filtering.
  af9013 frontend tuner bus lock and gate changes v2
  af9015 bus repeater
  af9013 Stop OFSM while channel changing.
  af9013 empty buffer overflow command.

 drivers/media/dvb/dvb-usb/af9015.c   |  220 +++++++++++++++++++++-------------
 drivers/media/dvb/frontends/af9013.c |   18 +++-
 drivers/media/dvb/frontends/af9013.h |    5 +-
 3 files changed, 158 insertions(+), 85 deletions(-)

-- 
1.7.5.4

Re: [PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[Antti Palosaari]

On 11/12/2011 05:57 PM, Malcolm Priestley wrote:
> Here is the lastest patches, for dual tuner and other fixes on the patchwork server.
>
>
> Malcolm Priestley (7):
>    af9015 Slow down download firmware
>    af9015 Remove call to get config from probe.
>    af9015/af9013 full pid filtering.
>    af9013 frontend tuner bus lock and gate changes v2
>    af9015 bus repeater
>    af9013 Stop OFSM while channel changing.
>    af9013 empty buffer overflow command.
>
>   drivers/media/dvb/dvb-usb/af9015.c   |  220 +++++++++++++++++++++-------------
>   drivers/media/dvb/frontends/af9013.c |   18 +++-
>   drivers/media/dvb/frontends/af9013.h |    5 +-
>   3 files changed, 158 insertions(+), 85 deletions(-)

Uhhuh, you have done rather much changes. Are you really sure those all 
are needed and OK ?

I think the issues are stream corruption and I2C some write fails. As I 
did some tests earlier it looked like I2C writes happens to fail when 
you program tuner and it is interrupted by some other command (read_snr, 
read_status, etc.).

regards
Antti



-- 
http://palosaari.fi/

Re: [PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[Antti Palosaari]

On 11/12/2011 06:11 PM, Antti Palosaari wrote:
> On 11/12/2011 05:57 PM, Malcolm Priestley wrote:
>> Here is the lastest patches, for dual tuner and other fixes on the
>> patchwork server.
>>
>>
>> Malcolm Priestley (7):
>> af9015 Slow down download firmware
>> af9015 Remove call to get config from probe.
>> af9015/af9013 full pid filtering.
>> af9013 frontend tuner bus lock and gate changes v2
>> af9015 bus repeater
>> af9013 Stop OFSM while channel changing.
>> af9013 empty buffer overflow command.
>>
>> drivers/media/dvb/dvb-usb/af9015.c | 220
>> +++++++++++++++++++++-------------
>> drivers/media/dvb/frontends/af9013.c | 18 +++-
>> drivers/media/dvb/frontends/af9013.h | 5 +-
>> 3 files changed, 158 insertions(+), 85 deletions(-)
>
> Uhhuh, you have done rather much changes. Are you really sure those all
> are needed and OK ?
>
> I think the issues are stream corruption and I2C some write fails. As I
> did some tests earlier it looked like I2C writes happens to fail when
> you program tuner and it is interrupted by some other command (read_snr,
> read_status, etc.).

I looked those just through and I want more information about every 
patch. Mainly I want to know which resolves which problem. As far as I 
understand, there is two problems;
1. register access fails sometimes (as I suspect in case of access some 
registers when firmware is programming tuner or doing some other task 
and does not expect it is interrupted)
2. stream corruptions

Is that possible you identify which changes fix 1 and what are for 2?

regards
Antti


-- 
http://palosaari.fi/

Re: [PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[Antti Palosaari]

On 11/12/2011 06:59 PM, Antti Palosaari wrote:
> On 11/12/2011 06:11 PM, Antti Palosaari wrote:
> I looked those just through and I want more information about every
> patch. Mainly I want to know which resolves which problem. As far as I
> understand, there is two problems;
> 1. register access fails sometimes (as I suspect in case of access some
> registers when firmware is programming tuner or doing some other task
> and does not expect it is interrupted)
> 2. stream corruptions
>
> Is that possible you identify which changes fix 1 and what are for 2?

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

That was easy to guess after I2C mux approach didn't fixed errors 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg36709.html

If someone would like to see how that new mux can be used, take a look here:
http://www.otit.fi/~crope/v4l-dvb/af9015_i2c_mux.patch



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 will now continue implement get_if() for AF9013 and tuners it uses.


regards
Antti

-- 
http://palosaari.fi/

Re: [PATCH 0/7] af9015 dual tuner and othe fixes from my builds.

[Antti Palosaari]

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/