From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14247 invoked by alias); 9 Feb 2012 14:23:14 -0000 Received: (qmail 14240 invoked by uid 22791); 9 Feb 2012 14:23:13 -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, 09 Feb 2012 14:22:48 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 85B812F78001 for ; Thu, 9 Feb 2012 14:22:47 +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 cO2n0-0NDebZ; Thu, 9 Feb 2012 14:22:47 +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, 09 Feb 2012 14:23:00 -0000 Message-Id: <20120209142246.290B12F78008@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/msg00245.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 #7 from Bernard Fouch=C3=A9 2012-0= 2-09 14:22:40 GMT --- Thanks for your message Ilija. I gave a look at the Kinetis I2C driver being discussed these days. I don't know if it has similar problems, I don't have a Kinetis target at hand. I t= hink so when I see this in the end of the ISR code: ... } else { /* * Invalid state? Some kind of spurious interrupt? Ignore it. */ I2C_TRACE("I2C spurious interrupt\n"); } ... However the interrupt seems to be cleared into the peripheral, it isn't mas= ked in the Cortex-M core itself (beginning of ISR code): ... // clear interrupt i2c_s->s |=3D FREESCALE_I2C_S_IICIF_M; ... If the interrupt is disabled in the peripheral itself, then the Cortex-M co= re may not see new interrupts (depends of the peripheral), so the interrupt pending condition won't happened. So if you test a driver that doesn't disable interrupts this way, for insta= nce any driver still compatible with a non Cortex-M core and ported to your Cortex-M target and that relies only on interrupt_mask/unmask/acknowledge (= like the generic serial driver), you should get the same problem. The easiest way to see it is to count the number of time the DSR is called,= and the number of times the DSR is called but does nothing. This second counter should be zero or near zero, depending of the way the peripheral works and if there are other hidden issues giving the same side effect (like the bug in the generic serial driver that triggers the TX interrupt before filling the TX FIFO). BTW I found that counting the times a DSR is run without doing nothing gives valuable info about a driver's sanity and tells if in depth analysis of the driver is required. I also count the number of data that comes in/out, the number of times the DSR is called, and the ratio data_in_out/dsr_calls gives also indication about the driver's efficiency. When I started looking at the generic serial driver ported to the the LPC17= XX, IIRC, this ratio was <1 byte exchanged per DSR call(!). Having 16 bytes FIF= O it was obvious I had to open the bug chase even if the code is more than 10 ye= ars old and considered to be reliable. My current ratio is now an average of 13 bytes processed per DSR calls (tes= ting file transfers), the RX FIFO trigger being set at 14 bytes: I know that I n= ow have something much more efficient and probably bug free. --=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-8815-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 14:23:04 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 14175 invoked by alias); 9 Feb 2012 14:23:03 -0000 Received: (qmail 14166 invoked by uid 22791); 9 Feb 2012 14:23:02 -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, 09 Feb 2012 14:22:48 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id 882112F78009; Thu, 9 Feb 2012 14:22:47 +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, 09 Feb 2012 14:23:00 -0000 Message-Id: <20120209142246.04E842F78006@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/msg00244.txt.bz2 Content-length: 2746 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001456 --- Comment #7 from Bernard Fouch=C3=A9 2012-0= 2-09 14:22:40 GMT --- Thanks for your message Ilija. I gave a look at the Kinetis I2C driver being discussed these days. I don't know if it has similar problems, I don't have a Kinetis target at hand. I t= hink so when I see this in the end of the ISR code: ... } else { /* * Invalid state? Some kind of spurious interrupt? Ignore it. */ I2C_TRACE("I2C spurious interrupt\n"); } ... However the interrupt seems to be cleared into the peripheral, it isn't mas= ked in the Cortex-M core itself (beginning of ISR code): ... // clear interrupt i2c_s->s |=3D FREESCALE_I2C_S_IICIF_M; ... If the interrupt is disabled in the peripheral itself, then the Cortex-M co= re may not see new interrupts (depends of the peripheral), so the interrupt pending condition won't happened. So if you test a driver that doesn't disable interrupts this way, for insta= nce any driver still compatible with a non Cortex-M core and ported to your Cortex-M target and that relies only on interrupt_mask/unmask/acknowledge (= like the generic serial driver), you should get the same problem. The easiest way to see it is to count the number of time the DSR is called,= and the number of times the DSR is called but does nothing. This second counter should be zero or near zero, depending of the way the peripheral works and if there are other hidden issues giving the same side effect (like the bug in the generic serial driver that triggers the TX interrupt before filling the TX FIFO). BTW I found that counting the times a DSR is run without doing nothing gives valuable info about a driver's sanity and tells if in depth analysis of the driver is required. I also count the number of data that comes in/out, the number of times the DSR is called, and the ratio data_in_out/dsr_calls gives also indication about the driver's efficiency. When I started looking at the generic serial driver ported to the the LPC17= XX, IIRC, this ratio was <1 byte exchanged per DSR call(!). Having 16 bytes FIF= O it was obvious I had to open the bug chase even if the code is more than 10 ye= ars old and considered to be reliable. My current ratio is now an average of 13 bytes processed per DSR calls (tes= ting file transfers), the RX FIFO trigger being set at 14 bytes: I know that I n= ow have something much more efficient and probably bug free. --=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-8817-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 09 21:46:54 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 2013 invoked by alias); 9 Feb 2012 21:46:53 -0000 Received: (qmail 1998 invoked by uid 22791); 9 Feb 2012 21:46:52 -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, 09 Feb 2012 21:46:24 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id 8A0052F78005; Thu, 9 Feb 2012 21:46:23 +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 1001453] CAN IO package: wider flags field, flag to report return to 'error active' mode 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: sergei.gavrikov@gmail.com X-Bugzilla-Status: NEEDINFO 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, 09 Feb 2012 21:46:00 -0000 Message-Id: <20120209214620.E06D92F78006@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/msg00246.txt.bz2 Content-length: 488 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001453 --- Comment #21 from Sergei Gavrikov 2012-02-09 21:46:13 GMT --- Now in CVS (a few small corrections was applied). Thank you for your contribution to eCos. Sergei -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.