>If u asked me (a nobody), I would avoid disabling interrupt at all
>possibilities.
:o) __Me too__ :o)
>So from a hardware point of view, why is disabling the interrupt needed?
H/W will signal the occurrence of the interrupt condition by raising a bit
in some register. As long as this bit is up the interrupt fires endlessly. S/W
has to handle the interrupt-cause in order to have the H/W lower that bit.
This has to be done in the interrupt routine - the only place where S/W is
not interrupted by the same source. If S/W can fully handle the condition
in this interrupt routine fine, if not because too long or other reasons and
S/W has to leave the interrupt routine before the condition is consumed
then S/W has to disable this particular interrupt source until the bottom-half,
as we name it under Linux does the work. If S/W doesn't do this the bottom-half
newer gets executed because the system will loop in interrupt context until
something bad happens ...
The bottom-half, tasklet or whatever name it has executes in kernel mode,
outside of the interrupt context and it has to re-enable this interrupt channel
at the end of the handling to keep the process of handling this interrupt channel
active. Lengthy explanation.... Sorry.
>and if there are 40 possible sources.....wow...the chances of missing
>these input is even higher. and especially with the additional
>overheads of having to process 40 different tasklets....
Don't worry... everything is under control :o)
H/W is here to help!
>for lower latency, i think tasklet is not the appropriate design as
>well....CMIW....but top-half is better, ie, write the logic into the
>interrupt handler itself. but be careful of overloading.
>but alternatively ONE tasklet handling all the 40 different sources
>sounds logical. this is because since it is multiplexed, it is
>guaranteed that only one source can come in at any POINT in time.
>Therefore, why not just one tasklet, with 40 different small ring
>buffer, and then a consumer in userspace or elsewhere (workqueue
>perhaps?) which will process the data to deplete the ring buffer?
>(search drivers/net/*.c, where they are commonly used).
OK - :o)
This is a mono-processor Linux system handling the configuration and
the User Interface. The real-time part is done by 40 DSPs running uCOS.
These guys communicate with the Linux part by sort of 8bit communication
interface mapped in the top-processor memory map as a suite of 8 eight
bits registers. There is a communication protocol a flow-control mechanism
and, of course an interrupt signal to ignite the exchange. Now, the top
level processor doesn't have 40 external interrupt lines. It has only two.
So the work is done by a CPLD which watches all these physical lines and
triggers the unique Linux interrupt line when something happens. It provides,
also a set of three-16bits registers containing the bit mask of interrupt
sources. This is not Linux IRQ multiplexing! Linux sees only one source
mapped on IRQ #1. Multiplexing happens @low-level H/W layer.
When Linux is interrupted executes the IRQ#1 routine. This routine asks the
CPLD to stop interrupting, scans the source masks and for each set bit
spawns a tasklet which will deal with the data exchange. There is flow-control
at DSP level - so no data is lost. The last living tasklet has to ask the CPLD to
re-enable the interrupt reporting under pain of breaking the communication flow.
The DSPs will maintain the interrupt request high as long as they have something
to send - their send buffer is not empty. Is for this reason I need to mask/unmask
the interrupts on this particular source.
> but Mulyadi's idea is a good one as well.....use some atomic variable.
> use of atomic variable avoid the need for spinlocks....or is your
> CPU single-CPU?
Is this atomic variable a regular Unix counting semaphore? Is this type of synch
safe in IRQ context?
Could you provide, please a precise pointer on such a call? or copy here a code snippet?
Thanks a lot for your interest in helping me,
I'm deeply indebt with some free beer,
StephanT
