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
This value is not used and is now gone.
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@10229 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
Saves time in the interrupt handler by eliminating the need to scan
through all of the slots in the cmd arrays. Also allows the reads from
ISR context to automatically grow as the latency grows. This ensures
that battery and hook state is actually checked every frame like
originally intended.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9966 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Trivial reformatting that preps it for some parallelizing the module
loads.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9965 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The card position is only used during startup so we don't need to carry it
around in the strucuture.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9964 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The voicebus cards only support the S110M FXS modules which are based on
the 3215. The module flags member was only used to hold whether we were
dealing with a 3210 or 3215 SLIC, so we can drop it since we always know
we'll have a 3215 based SLIC.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9963 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Cuts down on the overhead of constantly saving and restoring the
interrupt registers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9962 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change gets all the easy places and saves on array dereferences
when we already have the address of the module that we are interested
in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9961 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change is to primarily to clarify that the types are always mutually
exclusive.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9958 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This also allows us to add them to the union with the other module types so
they do not add to the memory usage if there aren't any QRV modules installed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9957 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move the data backing the mostly unused string away from the active
members of 'struct wctdm'.
The location where some of the other members of 'struct wctdm' are initialized
were moved so that wctdm_back_out_gracefully always has a fully formed
structure to work on.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9955 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We can already use the module type to determine presence of a module to
check. This also moves the background polling of the modules until after
the board is completely initialized because the module type may change
while the different types are being probed. This also means that we need
to preset the shadow registers for the FXS because otherwise the shadow
register will not have been read before the first time it's checked for
a power alarm.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9954 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of increasing system startup speed.
Splitting these two operations facilitate checking if there is a module
present synchronously on driver load from the actual load of the firmware and
configuration of the channels.
This will allow the presence of the VPM module to be flagged on the span
before registration, but load and configuration can happen in the background.
When the modules are eventually loaded via udev, there will be enough time
from the time the drivers are loaded to when dahdi_cfg will run to complete
the firmware load, eliminating the need to block the driver here.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9951 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In my opinion naming the VPM workqueues for each board is not worth the
extra complexity.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9950 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Currently the board will always be ready if the module initialization
function is complete but this change will facilitate allowing some of
the more time consuming configuration steps to happen in parallel on
system start.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9944 a0bf4364-ded3-4de4-8d8a-66a801d63aff
