[linux-dvb] Re: Strange problem with TT budget DVB-C - tuning ok but no data

[emard@softhome.net]

> 
> > Failures happen because the BRS initialization code is time-dependent
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > from reset or other conditions of internal saa7146 state that can't
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > be simply predicted if the time since 7146 reset is longer than some 10-20ms,
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > unless we construct a complex rps code that waits for internal events 
> > like BRS_DONE, and other and initialize during inactive states of those
> > events.
> 
> Why? _If_ the reset code correctly disables RPS/DMA etc. there should be
> no difference whether you start RPS/DMA after 10ms or after 1 year.

I can only speculate, but 7146 consists of internal hardware counters
and state registers that aren't accessible directly from the PCI interface
registers.
There's a one-way from PCI to this registers using "UPLOAD" mechanism,
you know it, fill the values and submit them to the internal hardware 
by setting some bits in MC1/MC2. OK, but not all internal registers that
describe state of 7146 can be uploaded this way, BRS line counters etc. 
they can just run on some noise that tuner provides when it's off station 
and if you hit them in wrong position with BRS upload, it will enter 
some irrecoverable state and result either as loss of stream or even 
require a reboot to return to sane state.

First measure is to completely shutdown tuner during initialization.
No VS, HS no activity at PORT's input. and then initialize. A good time
for this is only during module insertion. That's why I advocate this.

There are workaronds to do it with tuner online, see example of the the VBI 
initialization using rps for some analog cards. They upload registers 
after BRS_DONE using rps!

I had A BIG trouble to make autodetection of my budget patch and
had to reset and quickly do the autodetection if I wanted predictable
results. A.R.G.H

> I _hate_ drivers which have to be reloaded when unhandled error 
> conditions occur.

Me too, but this issuse simply has to be fixed. 

> If you completely remove device setup from start_ts_capture() you will
> probably create a driver which has to be reloaded after a failure...

I think not, because it will be initialized in more predictable
environment and then should never require reload. 
1. We must abstract what we want to initialized, 
2. call smart and unified initialization code that
   knows about all workarounds and checks itself did 
   it initialize well, then repeats steps if neede
3. Never touch initialization during usage!

Once good initialized 7146 BRS will run forever. Reinitialization
during opening of demux is not a robust thing, that's a risk that 
BRS will be woken up on a left leg. 
If we cannot make it reliable from the initialization phase
I'd rather see some ioctls for reinitialization.

Emard,