Upstream kernel 4.11, in commit (bd0f9b356d00aa241ced36fb075a07041c28d3b8
"sched/headers: fix up header file dependency on <linux/sched/signal.h>"), now
requires users of signal_pending to include the new linux/sched/signal.h file.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Some architectures, like arm, do not automatically pull in the definitions for
kzalloc and friends. This allows DAHDI to build on those platforms.
Originally reported to the asterisk-users mailing list here
http://lists.digium.com/pipermail/asterisk-users/2014-February/282338.html
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes an issue that affects TDM410 modules when there is not a module
installed in the first port, but there is an FXO module installed in the third
port.
When scaning for QRV modules in the first port, the 3rd port will have the
'hook' struct.qrv set to 0xff. When a QRV module is not detected, that value
will be left, which then maps to an invalid state for both fxo.ring_state and
fxo.battery_state.
The result would be that FXO ports would fail to run the ring detector state
machine since it did not know what the current state was.
Now we'll just reset all the values in struct fxo or struct fxs to the expected
init state.
Internal-Issue-ID: DAHLIN-332
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
For the spans exported by the wctdm24xxp, the channels are not going to change
after they are already registered.
This eliminates a problem when analog spans are unassigned/reassigned and the
not_ready goes negative, thereby causing many warnings in the kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
In 2.6.2 I introduced an error in (41639330a "wctdm24xxp: Eliminate chance for
channel to be stuck in RED alarm.") which would get an FXO stuck in detecting an
ONHOOK event from the remote side. An FXO port could go into the
BATTERY_DEBOUNCING_LOST_ALARM state and then back to the BATTERY_PRESENT state
without sending the dahdi_hooksig up to Asterisk. Therefore, Asterisk would
never detect the state changes needed for a remote side disconnect.
This change adds two more states, BATTERY_DEBOUNCING_PRESENT_FROM_LOST_ALARM and
BATTERY_DEBOUNCING_LOST_FROM_PRESENT_ALARM so that the state machine does not
miss any needed transitions when going back to BATTERY_PRESENT or BATTERY_LOST
regardless of why the debounce was started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
There was a code patch where it was possible to get stuck in RED ALARM on a
channel when debouncing the battery states. The state transitions would look
like this:
BATTERY_PRESENT -> BATTERY_DEBOUNCING_LOST -> BATTERY_DEBOUNCING_LOST_ALARM --
(send alarm up to asterisk) --> BATTERY_LOST -> BATTERY_DEBOUNCING_PRESENT ->
BATTERY_DEBOUNCING_PRESENT_ALARM -> BATTERY_DEBOUNCING_LOST -> BATTERY_PRESENT
In the above sequence there was never any transition from
BATTERY_DEBOUNCING_PRESENT_ALARM to BATTERY_PRESENT so the alarm to Asterisk was
never cleared and the channel stayed stuck.
Now when you loose battery when in the BATTERY_DEBOUNCING_PRESENT_ALARM go all
the way back to the BATTERY_LOST state instead of the BATTERY_DEBOUNCING_LOST
state so that all the events are properly sent up.
This fixes a regression introduced in 2.6.0 with commit (r10169 "wctdm24xxp: Use
interval for debouncing FXO battery." 874b76bd22).
Internal-Issue-ID: DAHDI-1019
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The logic to check for battery lost and battery present were using different
time bases. One was using jiffies and the other was using framecount. Since
framecount is always in milliseconds, let's use that to stay consistent.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Since r10683 "convert span->spantype to enumerated type" [1] the spantype was
changed from a string provided by the board drivers to an enumerated type that
is handled by the core of DAHDI. This was done to simplify the task of
dahdi_genconf since there is only one place to look for the valid strings that
can be exported in sysfs.
This eliminates the following warning on driver load:
Warning: Span %s didn't specify a spantype. Please fix driver!
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10683
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10729 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes a regression introduced in commit r10186 "wctdm24xxp: Use time
interval for debouncing FXO ring detect." [1] which was first released in
DAHDI-Linux 2.6.0. This only affects users with analog trunks whose providers do
not present 4 polarity reversals on the ring signals. The reporter of this issue
is based in South Africa.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168
In prior versions, the ring detector did not check for polarity reversals, only
the presence of ringing voltage unless fwringdetect or neonmwi_monitor mode was
set, and even when one of those modes were set, the driver only needed two
reversals to validate a ring. This commit allows the driver to always stay in
fwringdetect mode but restores the requirement for only two reversals.
Also included in this commit is a change to ensure that ringing is not reported
when debouncing lost battery which can happen when voltage is swinging through
0.
Reported-and-Tested-by: Jaco Kroon <jaco@uls.co.za>
Internal-Issue-ID: DAHLIN-298
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10719 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* This is a minimal convertion -- everything compiles and looks OK.
* We print a warning for spans registering without a spantype.
* Low-level drivers may later want (but not required)
to fold their internal representations to this canonical
representation -- it will save code and make it more readable.
Signed-off-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@10683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In addition to updating the year, this also adds some boilerplate to
dahdi-sysfs.c and dahdi-sysfs-chan.c that wasn't there previously.
Signed-off-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@10560 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Certain BIOSes appear to enable ASPM even though it is not fully supported by
the platform. Also, since the PCIe links for TDM cards are always in use it
does not make sense to allow them to transition to the disabled state.
Just turn off power management on the PCIe links completely. For more
information see http://lwn.net/Articles/449448/.
Internal-Issue-ID: DAHLIN-283
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10557 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In commit r10168 "wctdm24xxp: Use time interval for debouncing FXO ring
detect" [1], I inadvertently changed the debounce interval of the RINGOFF
event from 128ms to 512ms. The result was a potential failure to detect CID,
depending on line conditions, since Asterisk would bump the rx gains on the
channel in the middle of the CID spill as opposed to before the CID spill.
This fixes a regression first introduced in DAHDI-Linux 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168
Internal-Issue-ID: DAHDI-951
Reported-and-Tested-by: Jack Wilson <ljwilson@digitalav.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10473 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This patch removes support for kernel versions < 2.6.18, as those are
not actively supported in any major Linux distribution (except RHEL4,
which is in the "extended" support level of the product life cycle).
This removes much of the more #ifdef-rich parts of the code.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: 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@10472 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The DAHDI_ONHOOKTRANSFER ioctl was incorrectly setting the ohttimer to 0. The
result was that an FXS port was leaving the on-hook transfer state before
finishing the transmission.
This was discovered while looking at why ./fxstest dtmfcid was not able to
pass the DTMF callerid digits to an attached FXO port properly.
Fixes a regression introduced in r10167 "wctdm24xxp: Use interval for checking
FXS on hook transfer timer." [1], first released in 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10167
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10413 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the hook state on an FXS port changes before the channel is
configured with dahdi_cfg it is possible to erroneously force the line
feed register open without setting a timer to clear it.
The result would be a "dead" channel that cannot be cleared unless the
driver is reloaded and warning in the kernel log that "0 is an invalid
signaling state for an FXS module".
This change makes the OFF_HOOK to ON_HOOK change behave just as the
ON_HOOK to OFF_HOOK change has.
Internal-Issue-ID: DAHLIN-272
Reported-and-Tested-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10396 a0bf4364-ded3-4de4-8d8a-66a801d63aff
voicebus_release is already called as part of the wctdm_back_out_gracefully()
call. If an Hx8 card fails to initialize, this will eliminate warnings from
the kernel such as:
WARNING: at kernel/irq/manage.c:904 __free_irq+0x94/0x173()
Trying to free already-free IRQ 18
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10377 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Some of the VPM loading / probing threads use global system workqueues. They
might now be running when we abort early so we should wait for them to
complete their runs before freeing memory that may be in use.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10332 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irqmisses' is more a function of the device and there are better ways
to get to IRQ for a device than storing it in any DAHDI structures.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10276 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Increasingly, spans are implemented by devices that support more than a
single span. Introduce a 'struct dahdi_device' object which explicitly
contains multiple spans. This will allow a cleaner representation of
spans and devices in sysfs since order of arrival will not determine the
layout of the devices. This also gives the core of dahdi a way to know
the relationship between spans.
This generalizes similar concepts that were previously xpp specific. The
conversion of the xpp code was almost entirely done by Oron and Tzafrir.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10273 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10160 "wctdm24xxp: Probe for and configure modules in parallel."
did not properly setup the VPMADT032 for all ports on hybrid cards.
The most immediate sympton being that spans 3 and up on a hybrid
card would not come up in Asterisk even though they were out of
alarm. This was because the echo canceler was blocking messages on
the dchannels.
This does not affect any previously released versions of DAHDI-Linux
or users of the VPMOCT032.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10228 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Uses the linecompat member to determine what type of span it is. This will
allow removing T1/E1 flags from other places where the span type is stored.
This function also changes the return value from bool to int for the
inlines defined in include/dahdi/kernel.h. This is because not all
kernel versions include stdbool.h in the headers and it will conflict
with boolean values that are exported via module parameters on some
older kernels if dahdi included it globally.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10227 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Currently, the devicetype string was set both when the device was first
allocated and updated when an echocanceler was detected. For simplicity,
combine both these steps into a single function.
This change also replaces an improper use of strncat with strlcat.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10210 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A "(VPMADT032)" string is appended to the devicetype (as shown by
dahdi_scan) for the span if one is installed. Now append '(VPMOCT032)'
if one is installed as well.
Also, for the wcte12xp driver append the VPM name to the device type after
initially probing as opposed to only after the span is configured.
(Related to issue DAHDI-890)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10203 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The driver / FXO modules now always operate in a fwringdetect mode and the
module parameter was never checked anywhere. It is now gone.
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@10171 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Eliminate the assumption that the check function is going to be called
for every frame. Also use a state machine to make polarity debouncing
similar to the other debouncing code.
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@10170 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allows the driver the option of not calling the misc function for every
frame. This is part of preparation for moving misc processing out of
the interrupt handler. Also use a state machine for the various battery
states to unify the technique for debouncing the various signals in the
driver.
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@10169 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Do not assume the ring detection function is called for every frame.
Also change the debounce logic to a state machine to clarify what state
a port is in and unify the technique for debouncing the various signals.
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@10168 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of moving more of the module specific processing out of the
interrupt handler and allowing the interrupt rate to be slowed down.
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@10167 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of preparations for being able to optionally slow the interrupt
rate down and opening the door for moving more module processing out of
the interrupt handler.
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@10166 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Saved me time when reading the code so I don't have to lookup which position
in the index is what register for each of the modules.
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@10165 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The variable does not necessarily have anything to do with the frequency
of interrupts but is instead a count of sframes received. For example,
it is possible to slow the interrupt rate down on the voicebus cards to
one every 2 frames.
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@10164 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We can spend less time in interrupt context by not saving and restoring the
local interrupt state. This is a particularly noticeable improvement on debug
kernels with lockdep.
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@10163 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Closes a small window of opportunity where one CPU might free a VPM
instance that the interrupt handler may currently be using.
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@10162 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Wait until we have de-bounced the presence of battery before moving on the
check for changes in polarity. This removes the sometimes random
polarity messages generated on an FXO port when the far side drops
battery from a supervisor disconnect.
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@10161 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Use the newly create bg_create and bg_join to actually probe / configure
groups of 4 modules in parallel. This currently has to be done in groups
of four due to the way 4-port modules are identified relative to single
port modules.
This provides a dramatic improvement in driver load time. When loading a
single TDM2400 with 24 FXS ports before this change:
# time modprobe wctdm24xxp vpmsupport=0
real 0m46.674s
user 0m0.000s
sys 0m0.520s
And after this change:
# time modprobe wctdm24xxp vpmsupport=0
real 0m7.900s
user 0m0.000s
sys 0m0.070s
Note that the boards themselves are still configured serially. Board
configuration can be parallelized once the assignment of board position
is moved out of the function that is run in parallel. Otherwise it could
be possible for board numbers to switch on repeated loads.
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@10160 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Create a generic facility to spawn tasks to run in parallel. There are
interfaces already in the kernel for doing this, but they are not
supported on the full range of kernels that DAHDI must support.
This will be used to identify and configure FXS/FXO/B400M/VPM modules in
parallel.
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@10159 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10006 "wctdm24xxp: Add 'fastpick' module parameter." copied the
fast-off hook module parameter from the wctdm.c driver, but the setting
in that driver does not match the data sheet. The previous commit did
not actually change any of the significant bits in that register. Also,
that commit changed the timer, but did not disable the callibration
delay which is necessary for Type-II callerid.
The fastpickup option in the wctdm24xxp driver should now match the
fastpickup option in the wctdm driver.
DAHDI-224.
Reported-By: Kinnith Wallace <kwallace@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10148 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Really only *necessary* when SLAB debugging is enabled, but in that
case, can reduce the chance of latency bumps when first loading the
driver. Otherwise the constant slab poisoning / checking in interrupt
context from the kmalloc / kfrees is too much.
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@10144 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I failed to compile the commit exactly as it was committed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10008 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When true / 1 the FXO port will use a shorter off-hook calibration
delay. This is sometimes necessary in order to properly decode Type-II
Caller ID information which is sent shortly after an FXO port goes off
hook.
Defaults to 0 unless opermode is "JAPAN" then it will default to 1. This
functionality was ported from the wctdm.c driver.
DAHDI-854.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10006 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If an FXS port is configured to use kewl start signalling, when the FXS port
is "hungup" it should drop battery for 500ms so that any attached devices can
detect that the remote side has disconnected. The wctdm24xxp driver
since version 2.4.0 was only dropping battery for ~5-10 ms because it would
set "open" on the line, but then the next time it read the line feed register
state, it was setting the LINE feed register to the idle state.
This change checks if the line is forced open before setting the FXS port back
"onhook" so as to not turn on battery prematurely.
This fixes a regression introduced in r9070 "wctdm24xxp: Prevent FXS Proslic
staying in "Forward/Reverse OnHookTransfer...". DAHDI-849.
Checking for open on the line feed registered was originally suggested by Alec
Davis.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10002 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The firmware load has been moved into a workqueue to prevent the module load
from blocking for the duration of the firmware upload. This could be up to 40
seconds. Driver prevents configuration until firmware load is finished and
is_initialized() returns true.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9998 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Support enabled for the vpmoct032 echo cancellation module for the wctdm24xxp
and wcte12xp drivers.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9997 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In commit r9968 "wctdm24xxp: Allow more than one outstanding read at a
time" I introduced a regression where the transmit FIFO on the data
channel of a B400M could get locked up. The result would be constant
HDLC overflows when writing to the data channel.
This regression did not make it into any releases and did not exhibit
itself when crossing spans on a single B400M module. This is a partial
revert of commit r9968.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9977 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The board number dupliates the information that is available in the
location field. Exporting it as part of the description makes the name
dependent on the driver bind order which is not desirable.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9971 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Updates the CMD_BYTE macro to use precalculated offsets.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9970 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since every read needs to go through the complete voicebus pipeline, if
we know we're going to read multiple bytes we can queue them all up.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9968 a0bf4364-ded3-4de4-8d8a-66a801d63aff
