[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 #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-02-16 15:29:18 GMT ---
(In reply to comment #14)
> (In reply to comment #13)
> > Changes to the Kernel should be done with caution. I think that this addition
> > is not necessary. The desired functionality, for a given platform, can be
> > introduced by #defining HAL_VAR_INTERRUPT_ACKNOWLEDGE (and/or its cousins).
> 
> There are two problems:
> 
> - clearing the pending interrupt bit is completely different from acknowledging
> an interrupt. Acknowledgment is usually done at the end of DSR/ISR while
> clearing the pending interrupt bit must be done *before* reading the peripheral
> registers describing interrupt source(s): HAL_VAR_INTERRUPT_ACKNOWLEDGE is not
> a solution.
> 
> - if HAL_VAR_INTERRUPT_CLEAR_PENDING is added only to Cortex-M targets, then
> how can one share a driver between an arch not requiring clearing pending
> interrupt and Cortex-M cores? For instance the generic serial 16x5x driver?
> Today cyg_drv_interrupt_acknowledge() resolves to CYG_EMPTY_STATEMENT for
> Cortex-M, IMHO we need cyg_drv_interrupt_clear_pending() to resolve to
> CYG_EMPTY_STATEMENT for non-Cortex-M, hence one can write a driver using both
> cyg_drv_interrupt_acknowledge() and cyg_drv_interrupt_clear_pending() at the
> correct place so the driver can work in different arch.

Normally acknowledge should be enough. Regarding the IRQ re-triggering you have
found out, maybe (some of) LPC17xx peripherals employ pulsed rather than level
interrupts. Here is what's Cortex-M NVIC doc saying about it.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/Bhchgeei.html

Then, if we must implement HAL_VAR_INTERRUPT_CLEAR_PENDING I would suggest to
do it on LPC17xx variant or, if the problem appears on other variants consider
Cortex-M architecture level, and avoid patching kernel files. FYI as i
mentioned earlier I'll do some tests on Kinetis during next week.

-- 
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.