On Tue, Nov 11, 2008 at 3:22 AM, StephanT <stman937-linewbie@xxxxxxxxx> wrote:
> ________________________________
>>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.
to solve this problem, (for Intel x86 processor), when it goes into
interrupt mode, all external interrupt are disable via hardware.
but then again your hardware may be different......perhaps you are
trying to disable the DSP itself, correct? So you are right.....
i saw the same thing done in some OMAP video drivers.
> 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?
the following showed how to declare one (it is just a 4 byte
thing...in 32bit context):
./omap/dispc.c:
atomic_t map_count[OMAPFB_PLANE_NUM];
atomic_inc(&dispc.map_count[plane]);
atomic_dec(&dispc.map_count[plane]);
if (atomic_read(&dispc.map_count[plane]))
> 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,
>
no thanks, when i am drunk i cannot think :-).
> 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
