From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25658 invoked by alias); 23 Feb 2012 10:29:35 -0000 Received: (qmail 25640 invoked by uid 22791); 23 Feb 2012 10:29:34 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 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, 23 Feb 2012 10:29:17 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id DEF4A2F78003 for ; Thu, 23 Feb 2012 10:29:15 +0000 (GMT) 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 iSBK7TBpuL+W; Thu, 23 Feb 2012 10:29:15 +0000 (GMT) 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: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org 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, 23 Feb 2012 10:29:00 -0000 Message-Id: <20120223102914.362842F78008@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/msg00345.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 #19 from Bernard Fouch=C3=A9 2012-= 02-23 10:29:10 GMT --- (In reply to comment #18) > (In reply to comment #17) > > If you have at hand "The definitive guide to the ARM Cortex-M3" by Jose= ph Yiu: > > see chapter 7, "Interrupt Inputs and Pending Behavior" section, especi= ally > > figure 7.13, this is exactly what I observed. >=20 > I guess that in context of this bug you probably mean fig 7.14. (i guess = the > number at the bottom of fig.). Well on my edition there isn't any figure 7.14 ;-) (I think I have the first edition) >=20 > For solution I would return to cyg_drv_interrupt_acknowledge() since that= 's > what it's supposed to do: "Perform any processing required at the interru= pt > controller and in the CPU to cancel the current interrupt request on the > vector. An ISR may also need to program the hardware of the device to pre= vent > an immediate re-triggering of the interrupt." Our problem isn't usually in the ISR (unless it does all interrupt handling) and the feature concerned is different: we don't need to cancel "the current interrupt request" but to manage possible pending requests: we have to mana= ge interrupt requests THAT ARE NOT THE CURRENT INTERRUPT REQUEST, exactly what cyg_drv_interrupt_acknowledge() does not! > Only, it should be called later than it is called now. I acknowledge your > concern about generic serial driver but it has some conditional code alre= ady so > adding little-bit more wouldn't harm (or IMO the impact will be lower than > adding functions on Kernel level). If we take the serial driver as an example, cyg_drv_interrupt_acknowledge()= is called at the end of the ISR while interrupt pending conditions should be processed at the beginning or in the middle of the DSR (a strange place to acknowledge an interrupt , if we consider the driver code being read by som= eone unaware of the Cortex-M NVIC). You'll end up with multiple calls to cyg_drv_interrupt_acknowledge() in the code, bordered by conditional compilation specific to Cortex-M cores. And then you have all other 'Prime-cell' related drivers, shared between ar= ch (CAN, ADC, SPI for the driver I ported/checked) so the mysterious calls to cyg_drv_interrupt_acknowledge() in the middle or at the beginning of DSR wi= ll start to sprout in different places and if one looks at the original defini= tion of cyg_drv_interrupt_acknowledge() you shown then it's really impossible to grab the reason why such calls have to be inserted here and there. Or you change the definition of cyg_drv_interrupt_acknowledge(), describing= it as something that has a different meaning according to the type of arch involved while at the same time all cyg_drv_*() functions are arch independ= ent. I understand that changing a decade old API isn't a good news but I'm not s= ure that making the API difficult to understand because of a change of meaning = of a well known function is a better solution. Cortex-M brings a new interrupt handling model, maybe it's time to update the API spec also, instead of kee= ping it at any cost. --=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-8915-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 10:29:35 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 25655 invoked by alias); 23 Feb 2012 10:29:35 -0000 Received: (qmail 25641 invoked by uid 22791); 23 Feb 2012 10:29:34 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD 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, 23 Feb 2012 10:29:17 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id CD7BC2F78006; Thu, 23 Feb 2012 10:29:15 +0000 (GMT) X-Original-To: unassigned@bugs.ecos.sourceware.org Delivered-To: unassigned@bugs.ecos.sourceware.org From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power X-Bugzilla-Reason: AssignedTo 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: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org 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, 23 Feb 2012 10:29:00 -0000 Message-Id: <20120223102914.1554C2F78006@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/msg00344.txt.bz2 Content-length: 3400 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001456 --- Comment #19 from Bernard Fouch=C3=A9 2012-= 02-23 10:29:10 GMT --- (In reply to comment #18) > (In reply to comment #17) > > If you have at hand "The definitive guide to the ARM Cortex-M3" by Jose= ph Yiu: > > see chapter 7, "Interrupt Inputs and Pending Behavior" section, especi= ally > > figure 7.13, this is exactly what I observed. >=20 > I guess that in context of this bug you probably mean fig 7.14. (i guess = the > number at the bottom of fig.). Well on my edition there isn't any figure 7.14 ;-) (I think I have the first edition) >=20 > For solution I would return to cyg_drv_interrupt_acknowledge() since that= 's > what it's supposed to do: "Perform any processing required at the interru= pt > controller and in the CPU to cancel the current interrupt request on the > vector. An ISR may also need to program the hardware of the device to pre= vent > an immediate re-triggering of the interrupt." Our problem isn't usually in the ISR (unless it does all interrupt handling) and the feature concerned is different: we don't need to cancel "the current interrupt request" but to manage possible pending requests: we have to mana= ge interrupt requests THAT ARE NOT THE CURRENT INTERRUPT REQUEST, exactly what cyg_drv_interrupt_acknowledge() does not! > Only, it should be called later than it is called now. I acknowledge your > concern about generic serial driver but it has some conditional code alre= ady so > adding little-bit more wouldn't harm (or IMO the impact will be lower than > adding functions on Kernel level). If we take the serial driver as an example, cyg_drv_interrupt_acknowledge()= is called at the end of the ISR while interrupt pending conditions should be processed at the beginning or in the middle of the DSR (a strange place to acknowledge an interrupt , if we consider the driver code being read by som= eone unaware of the Cortex-M NVIC). You'll end up with multiple calls to cyg_drv_interrupt_acknowledge() in the code, bordered by conditional compilation specific to Cortex-M cores. And then you have all other 'Prime-cell' related drivers, shared between ar= ch (CAN, ADC, SPI for the driver I ported/checked) so the mysterious calls to cyg_drv_interrupt_acknowledge() in the middle or at the beginning of DSR wi= ll start to sprout in different places and if one looks at the original defini= tion of cyg_drv_interrupt_acknowledge() you shown then it's really impossible to grab the reason why such calls have to be inserted here and there. Or you change the definition of cyg_drv_interrupt_acknowledge(), describing= it as something that has a different meaning according to the type of arch involved while at the same time all cyg_drv_*() functions are arch independ= ent. I understand that changing a decade old API isn't a good news but I'm not s= ure that making the API difficult to understand because of a change of meaning = of a well known function is a better solution. Cortex-M brings a new interrupt handling model, maybe it's time to update the API spec also, instead of kee= ping it at any cost. --=20 Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the assignee for the bug. >>From ecos-bugs-return-8917-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 16:06:25 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 13298 invoked by alias); 23 Feb 2012 16:06:24 -0000 Received: (qmail 13287 invoked by uid 22791); 23 Feb 2012 16:06:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD 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, 23 Feb 2012 16:05:57 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id E56532F78006; Thu, 23 Feb 2012 16:05:55 +0000 (GMT) X-Original-To: unassigned@bugs.ecos.sourceware.org Delivered-To: unassigned@bugs.ecos.sourceware.org From: bugzilla-daemon@bugs.ecos.sourceware.org To: unassigned@bugs.ecos.sourceware.org Subject: [Bug 1001426] HAL for Kinetis Kwikstik X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org 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, 23 Feb 2012 16:06:00 -0000 Message-Id: <20120223160550.B59362F78006@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/msg00346.txt.bz2 Content-length: 621 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001426 --- Comment #6 from Ilija Kocho 2012-02-23 16:05:48 GMT --- Tomas I have checked the bug #1001450 patches in. Can you synchronize this port with CVS? Hint: Since this port is based on TWR-K40X256, IMO the easy way is to look at Attachment 1561 for diffs (with respect to original Kwikstik patch). Ilija -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.