Wednesday, July 23, 2008

more on data flow

In the ZAP_IRQ_HANDLER, (This is a macro defined in the zaptel.h) the data is copied from the hardware and back. This is done in a card specific manner. In tor2.c, the data is present in specific locations of xilinx memory region. We read and write from that region.

The next step is to read the rbs (robbed bits signaling) bits. These bits are read and compared with the stored rbs bits. If there is a difference, zt_rbsbits is called. The signaling bits are processed based on what is the type of the channel signaling (FXO, FXS, E1, E&M etc). This function in turn calls __zt_hooksig_pvt. This in turn stores the signaling bits in the event buffer of the channel and then wakes up the processes waiting on the eventbufq.

In case of tro2.c, the status byte is read and it is used in processing alarms. Time sync channel is also handled here.

The processing of the data happens in the bottom half. In case of tor2.c, it also depends on if the tasklets are enabled for the driver. If the tasklets are enabled, a corresponding function is scheduled to run. Else, the processing happens in the interrupt context only. In this case, tor2_run is called directly.

tor2_run then calls zt_receive and zt_transmit. This is done for every span. Also, the argument to the function is the span structure in each case.

No comments: