From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22449 invoked by alias); 27 Sep 2012 08:52:49 -0000 Received: (qmail 22441 invoked by uid 22791); 27 Sep 2012 08:52:48 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Sep 2012 08:52:44 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id AB7D22F7800E for ; Thu, 27 Sep 2012 09:52:42 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8BVGnqzFtKG; Thu, 27 Sep 2012 09:52:42 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: HAL X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: bernard.fouche@kuantic.com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: nickg@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Thu, 27 Sep 2012 08:52:00 -0000 Message-Id: <20120927085241.BD1502F7800D@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2012/txt/msg01264.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001456 --- Comment #26 from Bernard Fouch=C3=A9 2012-= 09-27 09:52:36 BST --- (In reply to comment #25) > But I wouldn't overstate the problem, as far I can tell this will only ha= ppen > with certain designs of devices, and only then if certain situations comb= ine, > which therefore makes it uncommon. That's not to say it's irrelevant, but= it's > not like it happens every interrupt or anything like that. If you're not looking for this problem, you won't see it :-). For instance you send X KB of data in a FIFO based driver (say the UART) and you don't count the number of times the ISR/DSR sequence is triggered but j= ust check that the UART traffic is correctly sent: everything seems fine since = the job is done. But if you start counting ISR/DSR then you wonder why you have a number of ISR/DSR that is bigger, sometimes much much bigger, that the number of bytes you sent (or have received) while with a FIFO you should have a lower numbe= r of ISR/DSR compared to the number of bytes sent/received(otherwise the interes= t of the FIFO is questionable). This is how I ran into this issue, first with the UART driver then I found = it with the other drivers I considered (SSP, CAN). --=20 Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are on the CC list for the bug. >>From ecos-bugs-return-9836-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Sep 27 11:05:32 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 24209 invoked by alias); 27 Sep 2012 11:05:31 -0000 Received: (qmail 24196 invoked by uid 22791); 27 Sep 2012 11:05:31 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Sep 2012 11:05:24 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 6BEAF2F78001 for ; Thu, 27 Sep 2012 12:05:23 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5RlslVEkvOY; Thu, 27 Sep 2012 12:05:23 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: HAL X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: nickg@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 27 Sep 2012 11:05:00 -0000 Message-Id: <20120927110518.158192F7800B@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org Delivered-To: mailing list ecos-bugs@sourceware.org X-SW-Source: 2012/txt/msg01265.txt.bz2 Content-length: 1657 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456 --- Comment #27 from Ilija Kocho 2012-09-27 12:05:14 BST --- (In reply to comment #25) > I still think this needs to be commented on by Nick as it involves a > significant change to the HAL definition, and he's both the HAL in general and > specifically Cortex-M HAL architect. So I'm assigning this to him and see if he > grumbles :-). He can always assign it away if he's not interested in commenting > on the API change. > > But I wouldn't overstate the problem, as far I can tell this will only happen > with certain designs of devices, and only then if certain situations combine, > which therefore makes it uncommon. That's not to say it's irrelevant, but it's > not like it happens every interrupt or anything like that. Jifl, I think that we ought to resolve this issue. In order to avoid API extension I proposed usage of cyg_drv_interrupt_acknowledge() (effectively unused by Cortex-M) for which Bernard has arguments that I respect (our discussion in comment #13 till comment #20). On the other hand the addition proposed by Bernard does not affect other architectures because for them it compiles to empty statement so it could be considered safe. The questions (for me) are: - Is there other alternative way to fix this issue? - If we add Bernard's function and associated macro do we bloat our API or not? Ilija -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.