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