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

["Robert Schlabbach" <robert_s@gmx.net>]

From: <emard@softhome.net>
> 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.

That's true. The solution to this is to put some PAUSE commands into the
RPS code which wait for the right state of the line counters. Each time you
(re)start streaming the RPS task must first pause until the BRS is in the
right 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.

That is not needed if you write the RPS code correctly as written above. I
have implemented quite complex RPS code in my Windows driver which
automatically fills a "hardware queue" of buffers and can be paused at any
time (even while waiting for the right BRS state!) by setting an RPS
signal, and acknowledges when it entered the paused state with another
signal, so that the driver can fully synchronize the with RPS task at any
time. Restarting after pause works in a similar fashion: Driver sets RPS
signal, RPS task "wakes up", acknowledges "run" request and waits for the
right BRS state, then starts filling the next buffer in the "hardware
queue". While waiting for the right BRS state, it also waits for the
"pause" RPS signal in case the driver tries to pause the streaming again
before any data has been received from the demodulator.

That code works 100% reliable for me. It took me months, if not years to
figure out, though, and I must have completely rewritten it at least half a
dozen times before I got it right ;)

Regards,
--
Robert Schlabbach
e-mail: robert_s@gmx.net
Berlin, Germany