This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Wed, 15 Feb 2012 11:28:57 +0000
- Subject: [Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power
- Auto-submitted: auto-generated
- References: <bug-1001456-777@http.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 #14 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-02-15 11:28:54 GMT ---
(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.
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.