I need to service a piece of hardware about every 400-500
microseconds, but I really don't want to change the value of HZ, which
in my version of the 2.6 kernel is 1000. The hardware doesn't have an
interrupt so the nasty hack I've been doing is to service the hardware
repeatedly in a loop for about 600 microseconds by watching the
do_gettimeofday(), set a timer for the next jiffy and repeat. This leaves less than 400 microseconds / millisecond for the kernel and anything else on the system to run.
Obviously, this sucks, but it does work. I am working with the
hardware guy to add an interrupt to the hardware. However, I don't
want every user of the hardware without the interrupt to have to
rebuild the kernel with a different value of HZ. So does anyone have
any better ideas on what I can do?
Thanks,
Rick Niles.
On Wed, Nov 23, 2005 at 03:39:17PM -0500, Rick Niles wrote:
> I need to service a piece of hardware about every 400-500
> microseconds, but I really don't want to change the value of HZ, which
> in my version of the 2.6 kernel is 1000. The hardware doesn't have an
> interrupt so the nasty hack I've been doing is to service the hardware
> repeatedly in a loop for about 600 microseconds by watching the
> do_gettimeofday(), set a timer for the next jiffy and repeat. This leaves less than 400 microseconds / millisecond for the kernel and anything else on the system to run.
>
> Obviously, this sucks, but it does work. I am working with the
> hardware guy to add an interrupt to the hardware. However, I don't
> want every user of the hardware without the interrupt to have to
> rebuild the kernel with a different value of HZ. So does anyone have
> any better ideas on what I can do?
Use the RTC interrupt generator perhaps (if you have one)? Call the
hardware people nasty things to tell them how dumb it is to make
hardware that requires frequent service without an efficient way to tell
the system when to do this. Polling is never efficient, although it is
sometimes faster (although not usually in my experience). :) After all
how did they think you were going to use the hardware?
Len Sorensen
On Wed, 2005-11-23 at 15:39 -0500, Rick Niles wrote:
> I need to service a piece of hardware about every 400-500
> microseconds, but I really don't want to change the value of HZ, which
> in my version of the 2.6 kernel is 1000. The hardware doesn't have an
> interrupt so the nasty hack I've been doing is to service the hardware
> repeatedly in a loop for about 600 microseconds by watching the
> do_gettimeofday(), set a timer for the next jiffy and repeat. This leaves less than 400 microseconds / millisecond for the kernel and anything else on the system to run.
>
> Obviously, this sucks, but it does work. I am working with the
> hardware guy to add an interrupt to the hardware. However, I don't
> want every user of the hardware without the interrupt to have to
> rebuild the kernel with a different value of HZ. So does anyone have
> any better ideas on what I can do?
Have you looked at Thomas Gleixner's ktimer/HRT patches. It gives you a
way to set a timer to go off within a jiffy.
http://tglx.de/ktimers.html
-- Steve
On Wed, 23 Nov 2005, Rick Niles wrote:
> I need to service a piece of hardware about every 400-500
> microseconds, but I really don't want to change the value of HZ, which
> in my version of the 2.6 kernel is 1000. The hardware doesn't have an
> interrupt so the nasty hack I've been doing is to service the hardware
> repeatedly in a loop for about 600 microseconds by watching the
> do_gettimeofday(), set a timer for the next jiffy and repeat. This leaves less than 400 microseconds / millisecond for the kernel and anything else on the system to run.
>
> Obviously, this sucks, but it does work. I am working with the
> hardware guy to add an interrupt to the hardware. However, I don't
> want every user of the hardware without the interrupt to have to
> rebuild the kernel with a different value of HZ. So does anyone have
> any better ideas on what I can do?
>
> Thanks,
> Rick Niles.
Use the RTC if you have an ix86-type machine. It interrupts on
IRQ8 and works fine. It can be programmed at 2048, 1020, 512, etc.,
ticks/per second. I have used it to create a precision state-machine
for handling a 24-bit ADC where it is important to grab stuff at
at repeatable times so that IIR filtering works.... basically:
interrupt
switch(state++)
{
case 0:
set_mux();
break;
case 1:
settle();
break;
case 2:
convert();
break;
case 3:
settle();
break;
case 4:
get_result()
do_iir_filter()
state = 0;
break;
}
Note that there is a global spin_lock called 'rtc_lock' that you should
use to prevent anybody from mucking with the chip behind your back.
Since you need to sample your hardware at fixed intervals, the RTC
interrupt is ideal. Just remember to put everything back when you
unload your module! Also, leave the index register (0x70) at 0 before
you release the spin-lock. That keeps a power-failure from trashing
the contents of CMOS (it could only trash seconds).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Well, I think the best answer for a distribution kernel without making a
any patches or rebuilding anything is to use the "register_rtc()" hook
in the rtc driver. I tried it and it works really well. This way my
device driver can drop into a Fedora system without the user having to
rebuild anything (other than my driver).
If I want to get fancy I could check to see if IRQ 8 is taken and use
it directly if it's not, i.e. the RTC driver isn't loaded. If IRQ 8 is
taken, check for the RTC driver and then use that via register_rtc().
In the unlikely event that IRQ 8 is taken and it's not by the RTC
driver, then I guess the user's out of luck.
Thanks for all the suggestions, they've all been good, but I'm trying
avoid steep requirements on usage of this driver.
Rick Niles.