Updated 19 April 2004
The VIA C3 processor includes a powersaving feature whereby the CPU clock multiplier may be changed while the CPU is operating. VIA calls this feature "longhaul"(tm).
The longhaul driver included with the 2.4 kernel does not work on the most recent VIA C3 CPUs. So I wrote my own. You can download it here.
The tarball includes a README file. Read the README file carefully. I will not be held responsible for damage which you may inflict upon your CPU.
There is a known conflict between longhaul and the lirc application. Here is some info on the conflict copied from the viaarena thread.
Just a note to stop others going through the same pain I just have, but longhaul
doesn't play fair with lirc_serial.o. The result is that you can see the codes with "mode2"
and can even train for a new remote control with "irrecord". However, if the cpu speed
changes between the irrecord and the use of the remote control, or worse during the use of
irrecord, then the result is that the key presses aren't correctly decoded. As for using the
pre-recorded remote control definitions, FORGET IT...
Now my temporary solution has been to do
% rmmod longhaul_governer
% echo "8" > /proc/longhaul
and then use one of the pre-recorded remote control definitions. I suspect the issue is that
some timing of the serial ports are defined during the boot of the machine and if longhaul slows
the machine up afterwards, then these are no longer valid. If anyone can suggest a better
solution, I'm interested since I'd like to use the governer if possible,
Regards
and more details in a subsequent message ...
... The COM2 to which the homebrew IR adapter is
connected has its uart disabled, so its normal that setserial has
now effect. Reading the lirc_serial.c code, the timing is initialized
at load time by the code
static inline int init_timing_params(unsigned int new_duty_cycle,
unsigned int new_freq)
{
unsigned long long loops_per_sec,work;
duty_cycle=new_duty_cycle;
freq=new_freq;
loops_per_sec=current_cpu_data.loops_per_jiffy;
loops_per_sec*=HZ;
/* How many clocks in a microsecond?, avoiding long long divide */
work=loops_per_sec;
work*=4295; /* 4295 = 2^32 / 1e6 */
conv_us_to_clocks=(work>>32);
/* Carrier period in clocks, approach good up to 32GHz clock,
gets carrier frequency within 8Hz */
period=loops_per_sec>>3;
period/=(freq>>3);
pulse_width = period*duty_cycle/100;
space_width = period - pulse_width;
So as you see the timing of the pulse and space widths are
1) Calculated from HZ and other data initialized at boottime (This might be different in 2.6)
2) Fixed once when lirc_serial is loaded.
So it is also normal that reloading lirc_serial doesn't help
This is a real pain, as I can't use the Haupagge remote directly with my PVR250 as it
uses the same RC5 commands as my television.....