[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling: wasted processing power

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456

--- Comment #26 from Bernard Fouché <bernard.fouche@kuantic.com> 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 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.

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 just
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 number of
ISR/DSR compared to the number of bytes sent/received(otherwise the interest 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).

-- 
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.
>From ecos-bugs-return-9836-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Sep 27 11:05:32 2012
Return-Path: <ecos-bugs-return-9836-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
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 <ecos-bugs@ecos.sourceware.org>; 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: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-13@http.bugs.ecos.sourceware.org/>
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: <ecos-bugs.sourceware.org>
List-Subscribe: <mailto:ecos-bugs-subscribe@sourceware.org>
List-Post: <mailto:ecos-bugs@sourceware.org>
List-Help: <mailto:ecos-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
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\x1001456

--- Comment #27 from Ilija Kocho <ilijak@siva.com.mk> 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.