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
When the driver begins to initialize a device it conducts a read/write
test on one of the framer registers. The driver ignores the result of
that test and results in much output spammed to the kernel logs for a
failed card since the driver doesn't then try to unbind from the device.
What was getting spammed:
wcte12xp 0000:03:01.0: Timeout in t1_getreg
wcte12xp 0000:03:01.0: Wrote '0' but read 'fffffffb'
Now abort the bind if the read / write test fails.
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@10155 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If LIVE_DAHDI_FREEPBXDB=yes is set in live.conf, live_dahdi will also
generate FreePBX astdb entries for the FXS entensions it probed (using
the dahdi_genconf module freepbxdb).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10151 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
The logic loops through the static cards[] array to determine timing,
but the subloop was based off the current card's numspans member.
This could cause a null dereference in the case where two cards of
different span densities were connected via timing cables.
Reported-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10140 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10082 "wctc4xxp: Cleanup in-flight commands when halting due to
hardware error." introduced a lock imblance on the error path where the
cmd_list_lock would be unlocked twice when the board is halted due to a
hardware error. Thanks sparse.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10138 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10066 "wctdm24xxp, wcte12xp: Run the ISR with interrupts disabled."
requested that the interrupt handler be run in "fast" mode (disabled)
but this isn't necessarily guaranteed.
This patch makes the interrupt handler itself disable all the interrupts.
Linux commit 470c66239ef0336429b35345f3f615d47341e13b [1] contains a comment
about why this is necessary.
[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=470c66239ef03364
(closes issue DAHLIN-248)
Reported-and-Tested-by: Vladimir Mikhelson <vlad@mikhelson.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10118 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Currently dahdi_receive is called on all channels in the context of the
master dynamic span. If one span (not the master) receive two packets
before the master span received a packet, the older packet on the
dynamic span would end up lost because the "readchunk" for the
channels would be overwritten by the new packet. DAHLIN-245
Signed-off-by: Wagner Gegler <wagner@aligera.com.br> (License #6268)
Changed dahdi_ec_chunk to dahdi_ec_span.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10110 a0bf4364-ded3-4de4-8d8a-66a801d63aff
HAVE_NET_DEVICE_OPS was defined in the mainline kernel in commit
47fd5b83 which was first released in 2.6.29. Any kernels after that will
have those fields defined.
Mainline commit e2270ea62ae4d7a removed the feature test macros, so
the easiest thing to do is define HAVE_NET_DEVICE_OPS ourselves on the
kernels since it was committed.
This change is needed to compile against the 3.1 kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10109 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Astribank II FPGA firmware rev 9605. Includes two bug fixes:
* Error in checking EC licenses when the license was for exactly 64 or 128
channels.
* Proper handling of a slave FXO Astribank (in line with the quirks
handling from r10019).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10099 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI currently supports kernels >= 2.6.9. netdev_priv() has been in the
mainline kernel since versions 2.6.6 so it's available in all the
supported kernels. This change is needed to compile against the 3.1 kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10096 a0bf4364-ded3-4de4-8d8a-66a801d63aff
On one system I was seeing the board reset in the middle of a
transaction. Any commands that were on the response list when this would
happen would never be completed and the process would then be stuck in
an uninterruptible sleep. This change also prevents the driver from
sleeping in timer context, which would result in a kernel panic.
This change at least lets an error message propogate back to the user.
DAHDI-880
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10082 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In the rare case where spanconfig is called while there is pending data
on the hdlc channel, the hdlc_getbuf interrupt could try to read from
the hdlc buffer before the channel was fully setup. This could
potentially result in a null pointer dereference. This condition has
existed since the creation of the wcb4xxp driver.
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@10079 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When attaching software echocans to a channel, if there is a hardware
echocan available always give preference to them.
Revision 9995 "dahdi: Always attach hwec to a channel if available" had
an error where if a driver did not even support an option of hardware
echocan, dahdi-base would take that to mean there always was a hardware
echocan available on the channel.
DAHLIN-246
Reported-by: Michael L. Young
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@10070 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Revision 9886, "wcte12xp: Use the in-hardirq versions of
dahdi_receive/dahdi_transmit", changed the call into dahdi_receive and
dahdi_transmit to use versions that assume local interrupts are already
disabled. Not all versions of the kernel run interrupt service routines with
all interrupts disabled and therefore it was possible to lock up a CPU with a
recursive grab of the chan_lock.
When LOCKDEP was enabled (on debug kernels) interrupt handlers were run
atomically so this problem would only occur on pre 2.6.35 kernels that did not
have lockdep enabled.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10066 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The wcte12xp wasn't recognizing loopup/loopdown signals. The debounce was so
long that it was preventing the loopup/loopdown signals from being registered
properly. Removed the debounce entirely as it was unnecessary to the operation.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10064 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Revision 9750 "wct4xxp: Reduce the memory footprint of the hardware
echocanceler" reduced the number of bits used to store some structure
members. Some of the new field lengths were unable to store all the
possible values the API as used assigned to the fields, resulting in
channels never entering power down mode when they were disabled like
they were previously.
The change for byEchoOperationMode was found in testing the operation of
the VPMOCT032 which currently uses the same code. The others were done
via a review of the API doc.
This change represents negligable risk and contains no logic changes.
It only increases the memory footprint of the API instance in the
kernel.
Signed-off-by: Doug Bailey <dbailey@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@10060 a0bf4364-ded3-4de4-8d8a-66a801d63aff
live_dahdi: Add a new command: symlink_ast, to make the system's
/etc/asterisk/dahdi-channels.conf a symlink to the one generated by
'reload' / 'genconf'.
If the system dahdi-channels.conf is a generated one and has not edited,
there's no real harm with running this.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10057 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Make sure that the call to dahdi_chan_unreg() in free_pseudo() is
protected by the registration_mutex, like the other calls to that
function.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10056 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Required by CAS in latest (2.5) DAHDI versions.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10055 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This avoids a nag about a meaningless single-bit signed int.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10054 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the CPU becomes overly busy, merely printing the "Overflow in the
recieve_queue" messages becomes CPU-intensive on its own right.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10052 a0bf4364-ded3-4de4-8d8a-66a801d63aff
/etc/asterisk already gets generated at config. No need to re-create it
at genconf time.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10050 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The shutdown logic requires that all CPUs see that the INITIALIZED bit
has been cleared. Otherwise it may be possible for the workqueue to run
after the hardware resources have been released.
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@10047 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the OCT6104E-256D.ima Octasic firmware was downloaded to the build
directory, install it over with the rest of the firmware files.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10038 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If set to true (default) a HWEC, if available on the channel, takes
priority over any software echocan configured in /etc/dahdi/system.conf.
This has historically been the default behavior in all released versions
of DAHDI that support module echocans.
Otherwise, hwec_overrides_swec is set to false, HWEC is chosen only via
the "echocanceller=hwec" directive.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10036 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Make sure you have etc/asterisk in the live tree before generating
configuration.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10028 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This adds module parameter 'ring_trapez'. When set, the wave form of
the ring tone is set to be a trapezoid, rather than sine. Thus making
the ring stronger.
This is a boolean parameter of the module xpd_fxs. Takes effect at the
beginning of the next ring.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10022 a0bf4364-ded3-4de4-8d8a-66a801d63aff
