From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13978 invoked by alias); 27 Sep 2012 18:09:56 -0000 Received: (qmail 13967 invoked by uid 22791); 27 Sep 2012 18:09:55 -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 18:09:50 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 7974D2F7800B for ; Thu, 27 Sep 2012 19:09:49 +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 4fIfxEP9qY5H; Thu, 27 Sep 2012 19:09:49 +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 18:09:00 -0000 Message-Id: <20120927180947.8A2A32F7800D@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/msg01269.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 #31 from Bernard Fouch=C3=A9 2012-= 09-27 19:09:39 BST --- Thanks Nick to have taken the time to answer to this report! (In reply to comment #30) >=20 > I wasn't sure what conclusion I would come to when I started writing this= , but > I think I have convinced myself that this is actually a non-issue. The pr= oposal > cannot eliminate these extra ISR/DSR calls completely; the problem is not= eCos > specific; it is not Cortex-M specific either; the issue only seriously af= fects > systems that are on the edge of being too slow to cope with the interrupt= rate. The issue happens for all peripherals that can trigger an interrupt for different and asynchronous reasons that the interrupt being processed. This can happen at any clocking speed: typically you fill a FIFO or a buffer for data output and the incoming side of the peripheral reports at that time that an event from outside is to be considered. Or you are emptying a FIFO = and the transmit FIFO is available again. Or the CAN buffer you filled previous= ly is now available while you are filling a newer buffer. The last time I checked, my system was running zero unneeded DSR while I can have up to 4 UART, SSP and CAN working so the proposed fix is efficient, at least in my case. I'm really curious if some other tried to count ISR/DSR regarding to the vo= lume of exchanged data, but at the moment nobody gave me counts made on another system. > The worst aspect of the proposal is that it spreads its tentacles into all > other architectures and device drivers. I agree...=20 >=20 > However, comment #7 contains a seed of a better solution. Many device dri= vers > are somewhat lazy in using cyg_drv_interrupt_mask() and friends to control > interrupt delivery; and it is this that is the main cause of the problem.= They > should really use peripheral registers to do this, where possible. Certai= nly > generic drivers like the 16x5x driver should. I switched the eCosCentric > version of this driver over to doing exactly this earlier this year and c= an > contribute a patch to do that for the public version. Other drivers shoul= d be > converted as and when convenient. Those devices that don't have local con= trol > of interrupts will just have to continue with the current approach and ac= cept > the consequences. IIRC some peripherals trigger an interrupt on the rising edge of an event b= ut won't make any interrupt if the enable interrupt bit is set in their interr= upt enabling register after the event occurred: if the peripheral event occurs exactly after the DSR reads the peripheral register (so the DSR thinks ther= e is no more job to do) but before the DSR re-enables peripheral interrupts then= an event may be lost. If this can happen, then there is no other solution than= to handle that interrupt pending bit. My guess is that the 'pending interrupt bit' is designed to avoid this race condition, at least you go for another ISR and/or DSR round but you don't l= ose anything. Pure speculation from me: HW peripheral designers may count on this feature= to lower the gate count of their cell, they send to the MCU the pulse of the e= vent when it occurs, they don't check when the interrupt register is written if = an interrupt condition should be triggered (have the MCU do a bit more so all peripherals can do and cost less). Unless someone else count ISR/DSR runs in a fast clocking system different = than mine, I'll stay convinced that this problem occurs frequently in many diffe= rent systems. --=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-9841-listarch-ecos-bugs=sources.redhat.com@sourceware.org Fri Sep 28 15:59:49 2012 Return-Path: Delivered-To: listarch-ecos-bugs@sources.redhat.com Received: (qmail 5471 invoked by alias); 28 Sep 2012 15:59:48 -0000 Received: (qmail 5460 invoked by uid 22791); 28 Sep 2012 15:59:47 -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; Fri, 28 Sep 2012 15:59:42 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id B2A372F7800C for ; Fri, 28 Sep 2012 16:59:40 +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 DUtKA1g8fiuY; Fri, 28 Sep 2012 16:59:38 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001606] Enable the cache on Kinetis in RAM startup mode 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: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: jifl@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: Fri, 28 Sep 2012 15:59:00 -0000 Message-Id: <20120928155937.CCB732F78001@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/msg01270.txt.bz2 Content-length: 2803 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001606 --- Comment #18 from Ilija Kocho 2012-09-28 16:59:26 BST --- Created an attachment (id=1945) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1945) Cache and DDRAM fixes/improvements 120928 (In reply to comment #5) Hi Jifl Here I attach a patch with some fixes that I have announced in my previous posts. In addition to addressing your remarks that I have accepted in comment #7 I have added some fixes to DDRAM configuration. Main improvements are PAD control, and slight memory optimization of initialization code for DDRAM. > Hi Ilija, > > Looking at this patch, I decided to look a bit closer at the Kinetis. Some > things to do with caches strike me as a bit unusual, but hopefully you can > clarify where my misunderstandings lie: > [ snip - discussed in previous replies] > > Not related to the particular patch, but still to do with caching > configuration... Some subsystems have their caching configuration set under > CYGPKG_HAL_KINETIS_CACHE, whereas others have them set in their own tree - or > at least SDRAM/DDR does, but I haven't looked more widely for others. And the > two key interfaces CYGINT_HAL_CACHE and CYGINT_HAL_HAS_NONCACHEABLE live under > a separate component CYGHWR_HAL_KINETIS_MEMORY_RESOURCES. Now they are moved out of CYGHWR_HAL_KINETIS_MEMORY_RESOURCES. >I think related > options ought to be kept in the same place. OR if there's a good reason why > not, a note should be placed in the description e.g. of > CYGPKG_HAL_KINETIS_CACHE pointing users in the right direction of other > cache-related configuration options. I assume you are referring to CYGHWR_HAL_KINETIS_DDR_NON_CACHED_SIZE_MIB and similar options. They are DDRAM rather than cache configuration options. But you are right, some explanation is good idea so I wrote explanatory descriptions for CDLs under DDRAM. Also I grouped "cachable" and "non-cachable" options so now DDRAM CDL should look simple and more compact. [snipped - replied earlier in other comments] > > - Incidentally some of the indentation in the kinetis CDL is a bit off, > e.g. underneath CYGHWR_HAL_KINETIS_FLEXNVM_FLASH_SIZE, at the end of > CYGPKG_HAL_CORTEXM_KINETIS_FLEXBUS and beginning of > CYGHWR_HAL_KINETIS_FLASH_CONF. Reformatted. The attached evolution patch does not affect (and should not be affected by) our eventual change of cache treatment (separate / unified). I have tested the code on K60 and K70, and I would like to commit it if you don't have objections. 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.