Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] final solution to the signalless operation problem found!! -> testers+RFC required
After consulting the specifications of the ves1893-chip i concluded that it
would be best to simply shut down the frontend at all so long no signal
arrives.
This avoids feeding the av7110 with "uncorrected blocks" = picked up noise
which it somehow tries to digest anyway as it seems, which leads first to
av7110_send_fw_cmd-errors and later to ARM-resets/crashes.
(Of course the ARM is not intended to digest an erroneous block the same way
as a normal block - therefore the the frontend sets the IEI-bit int the
header to allow the firmware to carefully handle this block which obviously
does not work)
There is a simple way for anybody who likes to just get it __working__stable__
without signal for the ves1893 (others probably very similar):
--- ves1x93.c.orig 2004-03-11 18:06:49.000000000 +0100
+++ ves1x93.c 2004-03-23 21:20:21.047714976 +0100
@@ -67,7 +67,7 @@
*/
static u8 init_1893_tab [] = {
- 0x01, 0xa4, 0x35, 0x81, 0x2a, 0x0d, 0x55, 0xc4,
+ 0x08, 0xa4, 0x35, 0x81, 0x2a, 0x0d, 0x55, 0xc4,
0x09, 0x69, 0x00, 0x86, 0x4c, 0x28, 0x7f, 0x00,
0x00, 0x81, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x80, 0x00, 0x31, 0xb0, 0x14, 0x00, 0xdc, 0x00,
This puts the ves1893 into standby-mode, the av7110 does not get feed with
data from it. I run it overnight and there wasn't a single glitch at all, the
ARM also reacts now much faster to ioctls than before - try it out!
---
Instead of above a more convenient solution for any kind of frontends would be
having the ioctl's FE_INIT and FE_SLEEP public instead of private.
I modifed vdr that it calls FE_SLEEP on opening the frontend (this could also
be default state in the driver itself) and if it first likes to tune with
this frontend it can call FE_INIT on demand and also put (unused) frontends
back to FE_SLEEP.
Since this requires a change of the dvb-frontend-interface i like to hear some
comments. If it can work this way we can suggest it to the driver developers.
The advantages of this approach i see are:
-no patching of driver required
-it works for all frontends which tend to crash the ARM (to be tested)
-safes power (and LNB/chip-lifetime) if frontends are not used
-in case of a "thunderstorm" and no signal one could still watch a recording
without crashing if vdr puts the frontend to sleep (so it's useful not only
for analogtv-users)
-just a change in frontend.h for the driver required (2 LOC's)
-probably less than 10 LOC's of change in vdr (dvbdevice.c) required
Guido
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.
Home |
Main Index |
Thread Index