On 01/11/13 16:30, Andrew Parlane wrote: > Hi, > > Another question regarding the ARM interrupt handling code. > > When an IRQ occurs we jump to IRQ: in hal\arm\arch\current\src\vectors.s > we save the previous state, potentially switch stack, take the scheduler > lock, find the IRQ number, call the ISR, and then call interrupt_end. > > interrupt_end() in kernel\current\src\intr\intr.cxx queues up the DSR if > asked to, and then unlocks the scheduler. As long as the scheduler > wasn't locked before the IRQ, this causes the scheduler to call any DSRs > that are queued up. This happens in call_pending_DSRs_inner() in the > same file. We disable interrupts, get the pointer to the DSR to call, > restore interrupts and call the DSR. > > In the case I've been describing we are still in the IRQ handler, and as > such the interrupts are disabled throughout the entirety of this, and > hence disabled in the DSR. > > Looking at: http://ecos.sourceware.org/docs-1.3.1/ref/ecos-ref.c.html in > the first paragraph it states: "This separation explicitly allows for > the DSRs to be run with interrupts enabled, thus allowing other > potentially higher priority interrupts to occur and be processed while > processing a lower priority interrupt." > > Am I missing something here?
call_pending_DSRs_inner() is called via cyg_interrupt_call_pending_DSRs() which is itself called by hal_interrupt_stack_call_pending_DSRs() in vectors.S. This last routine switches to the interrupt stack and enables interrupts before calling cyg_interrupt_call_pending_DSRs(). -- Nick Garnett Kernel Architect eCosCentric Limited http://www.eCosCentric.com The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No: 4422071 -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
