From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24719 invoked by alias); 1 Nov 2013 16:30:53 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 24700 invoked by uid 89); 1 Nov 2013 16:30:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: mail.carallon.com Received: from mail.carallon.com (HELO mail.carallon.com) (95.177.28.122) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Nov 2013 16:30:51 +0000 X-MDAV-Result: clean X-MDAV-Processed: mail.carallon.com, Fri, 01 Nov 2013 16:30:49 +0000 Received: from [172.20.1.41] by mail.carallon.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v13.6.0) with ESMTP id md50001443397.msg for ; Fri, 01 Nov 2013 16:30:47 +0000 X-Spam-Processed: mail.carallon.com, Fri, 01 Nov 2013 16:30:47 +0000 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 172.20.1.41 X-Return-Path: andrewp@carallon.com X-Envelope-From: andrewp@carallon.com X-MDaemon-Deliver-To: ecos-discuss@ecos.sourceware.org Message-ID: <5273D735.8060505@carallon.com> Date: Fri, 01 Nov 2013 16:30:00 -0000 From: Andrew Parlane User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ECOS] interrupts disabled during DSRs on ARM X-SW-Source: 2013-11/txt/msg00000.txt.bz2 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? Any comments would be welcome. Andrew Parlane Carallon ltd. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss