[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 #19 from Bernard Fouché <bernard.fouche@kuantic.com> 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 Joseph Yiu:
> > see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> > figure 7.13, this is exactly what I observed.
> 
> 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)

> 
> 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 interrupt
> 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 prevent
> 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 manage
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 already 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 someone
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 arch
(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 will
start to sprout in different places and if one looks at the original definition
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 independent.

I understand that changing a decade old API isn't a good news but I'm not sure
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 keeping
it at any cost.

-- 
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-8915-listarch-ecos-bugs=sources.redhat.com@sourceware.org Thu Feb 23 10:29:35 2012
Return-Path: <ecos-bugs-return-8915-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
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: <bug-1001456-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001456-777@http.bugs.ecos.sourceware.org/>
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: <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/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=1001456

--- Comment #19 from Bernard Fouché <bernard.fouche@kuantic.com> 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 Joseph Yiu:
> > see chapter 7, "Interrupt Inputs and Pending Behavior" section,  especially
> > figure 7.13, this is exactly what I observed.
> 
> 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)

> 
> 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 interrupt
> 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 prevent
> 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 manage
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 already 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 someone
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 arch
(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 will
start to sprout in different places and if one looks at the original definition
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 independent.

I understand that changing a decade old API isn't a good news but I'm not sure
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 keeping
it at any cost.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- 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: <ecos-bugs-return-8917-listarch-ecos-bugs=sources.redhat.com@sourceware.org>
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: <bug-1001426-777@http.bugs.ecos.sourceware.org/>
References: <bug-1001426-777@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, 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: <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/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\x1001426

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