[Asterisk-Dev] why not disable clock when using multiple Zaptel cards?

Andrew Kohlsmith akohlsmith-asterisk at benshaw.com
Fri Nov 26 12:18:55 MST 2004


On November 26, 2004 01:54 pm, Steven Critchfield wrote:
> Maybe because you may be confusing some terminology. For any T1 or E1
> interface there is timing on the wire and it is not directly tied to the
> IRQs. Timing on the T1/E1 spans are needed to keep them in sync with the
> remote end of the line. The interupt is fired after 8 bits of each
> channel are prepared. The data needs to be picked up before the next 8
> bits are ready. So the timing on the T1/E1 spans needs to be relatively
> perfect. The timing of the interupts has some wiggle room.

No I understand the terminology - I wasn't confusing span timing with TDM IRQ 
timing.

> As for eliminating the IRQs on any Zap card after the first and letting
> the driver handle each and every zap card there after on the same
> interupt, sounds interesting, but not all zap cards use the same driver.
> T100ps use wct1xxp driver, TDM400P uses wtdm somthing. If they used all
> the same drivers it might be possible, otherwise I think there is a
> kernel issue with servicing the interupt when your device didn't
> generate the interupt.

All cards use the zaptel module do they not?  It's just the "bottom-handler" 
modules (wctdm, wct1xxp, wct4xxp) which are different... they all reference 
and use code in the zaptel module, unless I'm mistaken.

As far as kernel issues I think you might have it backward -- the driver init 
code would say "ooh, there's already a zaptel timing source initialized, I am 
turning OFF the timer (and perhaps masking the IRQ) for this card and simply 
linking the service routine for the new card to the existing zaptel timing 
handler.

You aren't servicing an interrupt for a device that isn't generating it, 
you're servicing a card that didn't generate an interrupt (as far as the 
kernel is concerned, you'd be polling it).

Perhaps it's all moot but it seems hideous that you would have multiple 
"high-frequency" IRQs without good reason.

-A.



More information about the asterisk-dev mailing list