[asterisk-dev] [dahdi] Sync cable code for TE405P

[Shaun Ruffell]

On 02/14/2011 12:11 PM, Guillaume Knispel wrote:
> I'm investigating the behavior of synchronized TE405P cards and have the
> following question after i took a look at
> linux/drivers/dahdi/wct4xxp/base.c (DAHDI 2.4.0)
> 
> A/
> It seems that the synchronization source can only be updated when
> __t4_findsync() is called for the first card:
> 
> 	if (!wc->num) {
> 		/* If we're the first card, go through all the motions, up to 8 levels
> 		   of sync source */
> 
> It also seems that __t4_findsync() is only called for wc where
> T4_CHECK_TIMING has been set in checkflag, and that this is the case on
> startup of (a span on) the card, shutdown of (a span on) the card,
> alarm change state on (a span on) the card.
> 
> So if i understand correctly, the synchronization source can only be
> updated when one of said event happens on a span of the first card, and
> i can't make sense of this behavior.
> 
> Is this indeed the correct behavior for a subtle reason i missed or is
> it just a bug?
> 
> 
> B/
> Still in __t4_findsync(), we have the following code:
> 
> 	for (x=0;cards[x];x++) {
> 		for (i = 0; i < wc->numspans; i++) {
> 			if (cards[x]->tspans[i]->syncpos) {
> 
> Should it not rather be:
> 
> 	for (x=0;cards[x];x++) {
> 		for (i = 0; i < cards[x]->numspans; i++) {
> 			if (cards[x]->tspans[i]->syncpos) {
> 

After reading through your email and looking at the code, I think you
are correct.  The __t4_findsync() function is more or less of the same
form it was when it was first introduced in Zaptel revision 964 [1] and
it appears to make some assumptions about what cards are installed and
there are some hard-coded rules about how the sync source is selected.

Kevin P. Fleming mentioned in a hallway conversation that what most
likely needs to happen here is that the entire timing source / master
span selection needs to be completely mapped out before making any
changes to dahdi-linux so that it is clear what should be happening.

Somewhat related is mantis issue "0013205: [patch] bad master selection"
[2].  Since the sync source should also be the master span, and the user
should either have a definite way to select their preference order or
have it very clearly defined what the order is.  So, I consider this
issue more of an entire DAHDI issue as opposed to only related to the
wct4xxp driver.

Perhaps we either want to address it as part of that issue (and bump up
the priority...I know it's been assigned to me for awhile now) or open a
new issue?

[1] http://svn.asterisk.org/view/zaptel?view=revision&revision=964
[2] https://issues.asterisk.org/view.php?id=13205

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org