This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: on ARM: Using the FIQ vector
- To: Dan Hovang <dan dot hovang at cpen dot com>
- Subject: Re: [ECOS] on ARM: Using the FIQ vector
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Fri, 28 Jan 2000 08:50:09 -0700 (MST)
- Cc: ecos-discuss at sourceware dot cygnus dot com, "Hugo 'NOx' Tyson" <hmt at cygnus dot co dot ukx>
On 28-Jan-00 Dan Hovang wrote:
> Hugo 'NOx' Tyson wrote:
>>
>> Put another way:
>>
>> o short-term masking of *all* interrupts is done using the CPU
>> register, and you shouldn't let a thread that has done this sleep
>> whilst interrupts are disabled. (Macros with ENABLE/DISABLE/RESTORE
>> in them)
>
> We need to be able to let the FIQ be enabled constantly, no exceptions.
> I've removed the eCos FIQ code and rely on the IRQ to handle any timer
> (scheduling) and devicedriver IRQ's. The goal is that it should be
> enough to disable the IRQ in any critical sections of the kernel and
> completely leave the FIQ to the application.
>
>> It just *happens* that the CPU reg is preserved rather than always
>> re-enabled in load_context, because it doesn't really matter.
>
> It does to me, I think ... :-)
>
I agree [somewhat] with this approach. Currently FIQ interrupts are
handled using the eCos interrupt structure. While this works, in design,
it is probably too heavy weight for most FIQ interrupts (the emphasis
should be on _fast_).
What I have done in the past with FIQ interrupts (I was working with one
that has a 11KHz rate with little tolerance for delay) was to install
a different FIQ VSR, using the normal eCos support. The only problem
left was the one Dan mentions that IRQ processing in the system also
can mask the FIQ. I solved this ad hoc, similar to what Dan did, but
I think the proper solution is to have the FIQ support configurable in
the sytem such that systems that want total control over the FIQ can
get it without have to "hack" the sources.