Dear all,
I have been tasked with porting a driver for a PCI device from VxWorks /
Linux to eCOS 3.0. While most things look reasonably straight-forward, I
have a few queries relating to how a driver can schedule work to be done
in a thread context.
The ISR of this driver must handle interrupts that originate from
several distinct sources inside the device being controlled. These
sources are in reality DMA channels that can run independently of one
another, but share the same physical interrupt pin for signalling
completion of DMA. I'd like to be sure that my proposed interrupt
handling scheme won't lose interrupts.
First:
Will the following logic work?
ISR:
1. Read interrupt status register in device to sample what interrupt
sources are currently active. If nothing active, call
cyg_drv_interrupt_acknowledge and return 0.
2. For each active interrupt source set an "active flag" somewhere in
the device context structure (for use in the DSR).
3. Write to the device's interrupt status register to clear the
interrupt sources that we sampled in step 1.
4. Acknowledge the hardware interrupt using
cyg_drv_interrupt_acknowledge.
5. Return CYG_ISR_HANDLED | CYG_ISR_CALL_DSR.
DSR:
1. If active flag 0 is set,
clear active flag 0
do any necessary processing
2. If active flag 1 is set,
clear active flag 1
do any necessary processing
3. ... other sources ...
n. Return.
(assume that by design of the driver and hardware, an active flag can
never transition to "set" while the corresponding DSR processing is
happening)
Now my question is: suppose the DSR is executing any of steps 2 to n-1,
interrupt source 0 becomes active and the ISR runs to completion. Is the
DSR guaranteed to be rescheduled even though it is still executing?
If the answer is 'yes' then everything should be fine.
If the answer is 'no', then it seems that even masking the hardware
interrupt in the ISR and unmasking it right at the end of the DSR isn't
100% guaranteed to work correctly...
Alternatively, maybe I could create multiple interrupt objects using the
same vector / priority parameters, so that we have one ISR and one DSR
for each interrupt source in the device. That seems like an odd way to
do things, though. Is it legal?
Second:
I'm a bit confused about the need for cyg_drv_interrupt_acknowledge. If
my ISR is called as part of a chain of ISRs because our interrupt vector
is shared by other devices, shouldn't whoever traverses the chain (i.e.
not me) call cyg_drv_interrupt_acknowledge? If everyone in the chain
including me calls it, then the interrupt gets acknowledged multiple
times, which may be a bad thing. Or is cyg_drv_interrupt_acknowledge
smart enough to be a no-op in that situation?
Third:
It's quite common that a driver has to perform some periodic work in a
thread context, much like a DSR function. In our case, we want to read a
hardware monitoring chip periodically, to get temperatures and voltages
etc.
It looks like there has been some effort to "wall off" drivers from
everything else with their own API, as can be seen from the cyg_drv_*
functions. However, that API doesn't seem to have generalised timer and
work-scheduling functionality. So a driver has to use non-cyg_drv_*
functions. For example, the driver could call cyg_thread_create to
create a worker thread and have that thread wait on something in a loop.
If one were coming from Linux or Windows land, one might argue that it's
a job for a user-mode daemon that periodically makes a special call to
the driver, but that adds the complexity of having to create a special
user-mode interface.
I guess I'm wondering why there is this set of cyg_drv_* functions that
seem to be insufficient for nontrivial drivers. Are there some
guidelines on what non-cyg_drv_* functions a driver can/should use? Is
this API going to be expanded in the future? In any case, the
distinction between a "driver" and any other eCOS module seems a bit
artificial to me...
Thanks in advance for any answers / advice
Tom
========================================================
Tomas Whitlock, Senior Software Engineer
Alpha Data
4 West Silvermills Lane, 2570 North First Street,
Edinburgh, Suite 440
EH3 5BD San Jose
UK CA 95131
t: +44 131 558 2600 (408) 467 5076
f: +44 131 558 2700 (408) 436 5524
e: mailto:t...@alpha-data.com
w: http://www.alpha-data.com
========================================================
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
