From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16115 invoked by alias); 10 Jan 2012 16:28:31 -0000 Received: (qmail 16107 invoked by uid 22791); 10 Jan 2012 16:28:31 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT 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; Tue, 10 Jan 2012 16:28:04 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id EE9DE2FF0027 for ; Tue, 10 Jan 2012 16:28:02 +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 Pqh8Qd3OoC5O; Tue, 10 Jan 2012 16:28:02 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001435] CAN documentation (docs-latest) issues X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: CAN X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: bernard.fouche@kuantic.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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 10 Jan 2012 16:28:00 -0000 Message-Id: <20120110162801.5234D2FF0028@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/msg00078.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001435 --- Comment #6 from Bernard Fouch=C3=A9 2012-0= 1-10 16:27:57 GMT --- I met other issues while porting the LPC2XXX CAN driver to LPC17XX. These issues aren't related to the port itself, but by the CAN controller c= ell from NXP, and can be solved by a bit of documentation, hence I report them here: 1) missing flag bit definitions in CYPKG_IO_CAN If the CAN controller reports that it has regained bus access (for instance= it leaves 'bus off' state) or if it reports that it's moving from ERROR PASSIV= E to ERROR ACTIVE state, there are no flags defined in CYGPKG_IO_CAN to describe this: there are flags to report that the controller entered an error state/level, but no flags to report that the error state/level is exited.=20 However a major feature of the CAN bus is to define conditions to enter err= or states/levels, and to automatically exit from these. The event handler is called because it's in the event handler that the driv= er processes the details of the different situations. When an error state/leve= l is exited, the controller state is set to 'ACTIVE', but no flags are raised. The result is that the user callback function is triggered with a flag valu= e of zero, or an event obtained from cyg_io_read() can have a value of zero for = its 'flags' field. There are 3 solutions: - add more flags, but since the 16 bits of an event flag are all used, this means moving from a 16 bits value to represent flags to a 32 bits value. I'm not sure this is a good short term solution, because if such flags are adde= d, then existing drivers must be modified to support these new flags. However = not supporting such an important feature of the CAN bus should be fixed sometimes... - have the driver to avoid reporting such events, but it does not seem good either, because the user event handler won't be able to get all relevant ev= ents from the controller, some events of importance will be magically discarded. - document this as a 'feature': "If the event callback function is triggered with a flag value of zero, or = if an event read from cyg_io_read() provides a value of zero for the flags, th= en the user code must check the controller state because it may have changed. = If it's not the case, then the event can simply be discarded, it can have been triggered by the underlying hardware without always useful at the applicati= on level." (English isn't my mother language, please reformulate!) 2) spurious interrupts Doing many tests, I observed that sometimes an interrupt is triggered, but = in the DSR the interrupt cause has vanished. I think that I reach such weird situations because the CPU is clocking slowly (16MHz) compared to the CAN b= it rate I use (500Kb/s). The result is the same than above: an event with flags set to zero. The only explanation I have is related to the way the Interrupt and Capture register works (ICR) is designed: it is described as being made mostly of '= AND' gates between interrupt sources and the Bit Stream Processor of the CAN controller. If the interrupt cause has disappeared when this register is read, then the register bits are set to zero but for the RX interrupt. See bug #1001447 for another reason to think that the AND gate logic has side effects not sufficiently described in the datasheet. Reading ICR in the ISR is not a good solution either, the issue is clearly = time related, so reading ICR in the ISR will only increase the chance to get the interrupt source, but not to get it 100% of the time. Anyway, the result is similar to the first point, and solution 3 really see= ms to be the only reasonable solution. (For this particular case, I think I'll offer a CDL option to filter such interrupts directly in the DSR since the controller state did not change, and because the upper layer code has no me= an to understand what's going on.) Comments welcome... --=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-8648-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 16:28:24 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 16013 invoked by alias); 10 Jan 2012 16:28:23 -0000 Received: (qmail 16005 invoked by uid 22791); 10 Jan 2012 16:28:22 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT,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; Tue, 10 Jan 2012 16:28:04 +0000 Received: by mail.ecoscentric.com (Postfix, from userid 48) id DB8552F78001; Tue, 10 Jan 2012 16:28:02 +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 1001435] CAN documentation (docs-latest) issues X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: CAN X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: bernard.fouche@kuantic.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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 10 Jan 2012 16:28:00 -0000 Message-Id: <20120110162801.07D802F78001@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/msg00077.txt.bz2 Content-length: 4200 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=3D1001435 --- Comment #6 from Bernard Fouch=C3=A9 2012-0= 1-10 16:27:57 GMT --- I met other issues while porting the LPC2XXX CAN driver to LPC17XX. These issues aren't related to the port itself, but by the CAN controller c= ell from NXP, and can be solved by a bit of documentation, hence I report them here: 1) missing flag bit definitions in CYPKG_IO_CAN If the CAN controller reports that it has regained bus access (for instance= it leaves 'bus off' state) or if it reports that it's moving from ERROR PASSIV= E to ERROR ACTIVE state, there are no flags defined in CYGPKG_IO_CAN to describe this: there are flags to report that the controller entered an error state/level, but no flags to report that the error state/level is exited.=20 However a major feature of the CAN bus is to define conditions to enter err= or states/levels, and to automatically exit from these. The event handler is called because it's in the event handler that the driv= er processes the details of the different situations. When an error state/leve= l is exited, the controller state is set to 'ACTIVE', but no flags are raised. The result is that the user callback function is triggered with a flag valu= e of zero, or an event obtained from cyg_io_read() can have a value of zero for = its 'flags' field. There are 3 solutions: - add more flags, but since the 16 bits of an event flag are all used, this means moving from a 16 bits value to represent flags to a 32 bits value. I'm not sure this is a good short term solution, because if such flags are adde= d, then existing drivers must be modified to support these new flags. However = not supporting such an important feature of the CAN bus should be fixed sometimes... - have the driver to avoid reporting such events, but it does not seem good either, because the user event handler won't be able to get all relevant ev= ents from the controller, some events of importance will be magically discarded. - document this as a 'feature': "If the event callback function is triggered with a flag value of zero, or = if an event read from cyg_io_read() provides a value of zero for the flags, th= en the user code must check the controller state because it may have changed. = If it's not the case, then the event can simply be discarded, it can have been triggered by the underlying hardware without always useful at the applicati= on level." (English isn't my mother language, please reformulate!) 2) spurious interrupts Doing many tests, I observed that sometimes an interrupt is triggered, but = in the DSR the interrupt cause has vanished. I think that I reach such weird situations because the CPU is clocking slowly (16MHz) compared to the CAN b= it rate I use (500Kb/s). The result is the same than above: an event with flags set to zero. The only explanation I have is related to the way the Interrupt and Capture register works (ICR) is designed: it is described as being made mostly of '= AND' gates between interrupt sources and the Bit Stream Processor of the CAN controller. If the interrupt cause has disappeared when this register is read, then the register bits are set to zero but for the RX interrupt. See bug #1001447 for another reason to think that the AND gate logic has side effects not sufficiently described in the datasheet. Reading ICR in the ISR is not a good solution either, the issue is clearly = time related, so reading ICR in the ISR will only increase the chance to get the interrupt source, but not to get it 100% of the time. Anyway, the result is similar to the first point, and solution 3 really see= ms to be the only reasonable solution. (For this particular case, I think I'll offer a CDL option to filter such interrupts directly in the DSR since the controller state did not change, and because the upper layer code has no me= an to understand what's going on.) Comments welcome... --=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-8650-listarch-ecos-bugs=sources.redhat.com@sourceware.org Tue Jan 10 18:44:27 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 6521 invoked by alias); 10 Jan 2012 18:44:25 -0000 Received: (qmail 6493 invoked by uid 22791); 10 Jan 2012 18:44:19 -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; Tue, 10 Jan 2012 18:44:06 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 7DF752F78011 for ; Tue, 10 Jan 2012 18:44:05 +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 sZbJoPR+t2Rm; Tue, 10 Jan 2012 18:44:02 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001452] New: Select doesn't work correctly when Cyg_FlagValue > 32 bit X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Filesystem support X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: savin.zlobec@gmail.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: Message-ID: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 10 Jan 2012 18:44:00 -0000 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/msg00079.txt.bz2 Content-length: 1181 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001452 Summary: Select doesn't work correctly when Cyg_FlagValue > 32 bit Product: eCos Version: CVS Platform: All OS/Version: All Status: UNCONFIRMED Severity: minor Priority: low Component: Filesystem support AssignedTo: unassigned@bugs.ecos.sourceware.org ReportedBy: savin.zlobec@gmail.com CC: ecos-bugs@ecos.sourceware.org Class: Advice Request Created an attachment (id=1510) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1510) Fix for select() when Cyg_FlagValue > 32 bit If eCos flags value is configured to be > 32 bits (CYGIMP_FLAGS_64BIT) select() breaks if called from thread with id >= 32. Attached patch fixes this. BTW since there is no regular way to change flags value size this is a no issue for most. -- 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.