[linux-dvb] dib0700 problems (nova-T usb stick)
patrick.boettcher at desy.de
Thu Jun 7 13:01:56 CEST 2007
It is _no_ hardware restriction.
The symptoms described by Soeren is correct, but the conclusion is wrong.
In fact this behaviour seems to be specific to the open source driver, we
don't have this problem in our reference driver.
If I only would have time, I would take a look.
Did you try the new firmware?
On Thu, 7 Jun 2007, Stephen Rowles wrote:
> Soeren Moch wrote:
> >> mt2060 I2C read failed
> >> output in dmesg, and it fails to stream the TS.
> >> Looking at the front end status it never seems static, sometimes I get:
> >> Signal, Lock, Carrier, VITERBI, Sync,
> >> which all looks good. but other times I only get:
> >> Signal, Lock, Carrier, Sync
> >> or
> >> Carrier, VITERBI
> > As I can see the dib0700 USB bridge in this stick deactivates the
> > I2C controller during data streaming, so all I2C accesses to mt2060
> > (tuner) and dib7000pc (dvb-t demodulator) fail. Therefore you get
> > "I2C read fails" messages from mt2060 and uninitialized (random) data
> > for the frontend (dib7000pc) status.
> > Unfortunately there seems to be no independent I2C gate control call in
> > the dib0700 firmware...
> So.. .with this hardware restriction, having a "working" driver that
> behaves like the other devices is going to be hard?
> Could a fix for this be to ensure that in the driver if a tune request
> is sent, the driver stops streaming, tunes, then starts again? At the
> same time the front end status could be cached from just before
> streaming is started and this cached data returned when requested,
> rather than going to the device itself?
> Both of these seem a bit like a "hack" to me, but seem like they would
> bring the driver closer to behaving the way apps like VDR expect. If
> there is not way of accessing the real data, then at least a cached
> version from before streaming was started would provide some data.
> linux-dvb mailing list
> linux-dvb at linuxtv.org
More information about the linux-dvb