Changed the echocan factory name to a function (get_name) called to get the
name. This allows a factory to return a different name when being called in
reference to a channel such as in the case of hardware echo cancellers. To
further accommodate this change for HWEC, a new echocan_name function was
added to the span ops struct and is used in hwec_factory in dahdi-base for
all cards that support hardware echo cancellation.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9524 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This field was redundant and was only used in places where the factory's name could be used.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9523 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The loopup/loopdown T1 maintenance feature in the single through quad-span
drivers now function properly, according to AT&T TR54016, by sending a
full rate pattern down the line. T1.403 ESF/Data Link patterns are not
supported currently.
Also grouped all the maint reset register clears under a single irq lock
to crank the performance up past 11.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9516 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI_MAINT_LOOPSTOP is being removed due to the redundancy with
DAHDI_MAINT_NONE. Also removing some timing logic, as amount of time a
loopup or loopdown signal is held on the line, is now defined in
userspace with dahdi_maint.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9515 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The dahdi_span->maintq wait queue was very old and not being used so it
has been removed.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom..com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9514 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Renamed the NMF workaround message to the more informational
crc4-multiframe (mis)alignment message.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9461 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Push all tests for the DAHDI_FLAGBIT_NETDEV flag behind a
'dahdi_have_netdev' function so if CONFIG_DAHDI_NET is not defined the
compiler can just remove all the flag tests. Also, makes sure that the
bit is checked / set atomically.
(closes issue #9379)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9444 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The check for DEFINE_SPINLOCK was spread throughout the source tree. If
not defined we can just define it in inlucde/dahdi/kernel.h. Now
include/dahdi/kernel.h is the only place that references
SPIN_LOCK_UNLOCKED (which breaks lockdep checking if DEFINE_SPINLOCK is
otherwise defined in the kernel).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Review: https://reviewboard.asterisk.org/r/940/
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9411 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The registers on the device are already accessed with readl/writel and
the readchunk and writechunk are mapped into coherent DMA region. The
contents of those buffers should not be changing in the middle of any
transmit/receive prep call.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9400 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Normally you can see RBS bit states in dahdi_tool, but you might also
want them logged to dmesg for troubleshooting.
(issue #18025)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9399 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_tool was incorrectly reporting all spans to be in local timing
mode. This is because the driver tracks which span it's timing syncs to,
within the card local struct "wc". We have to manually go through and
copy timing updates to the span local structs because this is what
dahdi_tool actually reads.
dahdi-526
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9312 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This needs some more testing before it's on by default. If the card is
otherwise functioning, these messages may be confusing to the user. If
the card is not functioning, the driver can be reloaded with debug to
check for this condition.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
