[RTnet-developers] progress in real-time firewire project

[Zhang Y. <y.z...@st...>]

Hi, 
last week, I delved into the current firewire linux drivers, ie.,
ohci1394+ieee1394. Then I realized the biggest non-real-time point here is
the "task handover" between interrupt handler and the corresponding tasklet
for the events, like a received packet.The handover is done in the way of
"Bottomhalf", which is not considered to be real-time safe.  Both of the
interrupt handler and the tasklets are defined and registered in ohci1394.
The function hpsb_xxx, which is defined in ieee1394, for offering services
to the various high-level applications, is invoked in the tasklets of
ohci1394. There can be minimally 4 tasklets, respectively for 4 contexts: at
(asynchronous transmission) request, at response, ar(asynchronous reception)
request and ar response. When isochronous transaction is required, there
will be more.  But the demuliplexing is done by hardware. In interrupt
handler, the software reads the register of the hardware to get the context.

To change the bottomhalf handover, the stack manager mechanism seems to be
usable.One option is to build a separate stack_manager for firewire, another
is to arrange a new route for firewire in current stack_manager, which could
be totally different from the other routes for ethernet. I would like to
have your suggestions or questions for this.  

Currently I lack the knowledge of rtai to understand the internal working of
stack_manager. A simple questions is: when the "do_stacktask" of
stack_manager is woke up and start running, will it be scheduled away from
CPU, not because of the semaphore? Or will it be preempted by other
real-time task? 

Looking forward to your reply. 
 
Regards,
Zhang Yuchen
MSc Student
Control Engineering Group
University of Twente
The Netherlands