On Sat, Nov 8, 2008 at 6:47 AM, StephanT <stman937-linewbie@xxxxxxxxx> wrote: > Hello there, > > Environment is embedded Linux 2.4.18. > > Context is driver mapped on one interrupt coming from 40 possible > sources - everything being multiplexed by a FPGA. > > When the interrupt triggers the driver reads three FPGA registers to > discover the interrupt source. For each source it spawns a tasklet which > deals with the data transfer. The driver_interrupt_routine disables the > interrupt by masking it. The last living tasklet should re-enable (un_mask) > the > interrupt. > If u asked me (a nobody), I would avoid disabling interrupt at all possibilities. So from a hardware point of view, why is disabling the interrupt needed? 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.... search missing interrupts in google....seemingly it is a common embedded problem. 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). 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? for implementation ideas, how about drivers/net subdirectory, for eg, via-velocity.c, and lookup the velocity_intr() handler, thus re-using linux kernel's interrupt infrastructure, avoiding the need for worrying about synchronization among 40 different sources. just bunch them together as IRQF_SHARED. am i correct? > Problem: In the tasklet context how to find out if this tasklet is the last > living one? > > Thanks for your kind suggestions. > > StephanT. > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
