wake_up_interruptible() will change the state of waiting tasks back to
TASK_RUNNING, therefore, we want to ensure we set TASK_INTERRUPTIBLE
before checking the conditions that we're going to sleep on.
In practice, this closes a small window were the caller may be put to
sleep when the condition is true, and have to wait for another event to
come in order to wake from the sleep.
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@9467 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Just a cleanup patch that moves code into a standalone function. Real
change to follow.
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@9466 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'interruptible_sleep_on()' is the Linux equivalent of 'tsleep()'. When
we're sleeping for a condition, we can also just use
wait_event_interruptible to close a potential race where the condition
goes true between the time we checked it and when we go to sleep waiting
on the event.
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@9465 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Using semaphores as mutexes was removed from the kernel in 4882720b267b.
Just use straight semaphores now. 'DECLARE_MUTEX()' -> 'DEFINE_SEMAPHORE()'
and 'init_MUTEX()' -> 'sema_init()'.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
LKML-Reference: <20100907125057.562399240@linutronix.de>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9464 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Conference links do not appear to be in use anymore and they are now
removed. I could not find any references to this ioctl in the asterisk
repository, or zaptel user space tools.
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@9463 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
When using conference mode DAHDI_CONF_DIGITALMON ensure conf_chan is
set. Otherwise we dereference a NULL 'conf_chan'.
Fixes regression introduced in revision 9381
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9457 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes a regression introduced in revision 5916 where FXS modules based
on the 3210 were not properly detected.
(closes issue #18184)
Reported by: bsexton
Patches:
dahdi-fxo-detect.diff uploaded by bsexton (license 1133)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9456 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI does not support any kernels older than 2.6.9. No need
to keep the old HDLC interface support around.
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@9447 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'cmd_dequeue_vpmadt032' in the wctdm24xxp and wcte12xp drivers no longer
care about which frame they are on. The command will be packed into the
eframe specified by "writechunk".
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@9446 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'zt' is a carry over from the Zaptel days.
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@9445 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
It can be necessary to have low frequency filter for tx signal of DAHDI.
Otherwise, low-frequency signal from IP can reach a leased line, and
return back with nonlinear distortions. This will break an echo
canceler.
(closes issue #13562)
Reported by: biohumanoid
Patches:
dahdi_echocan_oslec.c.patch uploaded by biohumanoid (license 459)
I slightly modified the above patch in order to use echocan_process_tx
as the interface.
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@9443 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Add optional interface to allow software echo cans to process the
transmitted samples. Can be used for things like DC removal.
I used the following patches uploaded by biohumanoid but changed the
name of 'echocan_hpf_tx' to 'echoan_process_tx and put the changes
behind a compile time option.
(issue #13562)
Reported by: biohumanoid
Patches:
kernel.h.patch uploaded by biohumanoid (license 459)
dahdi-base.c.#2.patch uploaded by biohumanoid (license 459)
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@9442 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In zaptel commit 4096 [1], all the debouncing of ring signals were moved
into software as opposed to using the ring validation circuit in DAA.
That commit failed to remove the initial check and set of the ring
validation circuit.
[1] http://svn.digium.com/view/zaptel?view=revision&revision=4096
(closes issue #16894)
Reported by: rde42
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@9441 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the DSP ever finds it's way into a bad state it can be possible for a
timeslot to get 'wedged'. All attempts to create a channel in a wedged
timeslot will fail and the WARN_ON macro can quickly fill the logs.
This change adds some more debugging information (which timeslot is wedged)
along with the result code from the DSP and puts it all behind a
printk_ratelimit.
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@9437 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Just use the standard way to print messages associated with a particular
device. Also dropped the "Attached to device at" message since that
information is now printed on every print.
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@9436 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'service_dte' was only called in one place and is only two lines. I do
not think it is adding much anymore. Also, let compiler should decide if
'service_rx_ring' and 'service_tx_ring' should be inlined.
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@9435 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It appears that in Centos 4, the version of tar doesn't like the -o
flag, but will honor the --no-same-owner flag.
(closes issue #16063)
Reported by: tzafrir
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@9434 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Setting this configuration option would not have had any impact when a
hardware echo canceler was in use.
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@9432 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes a regression singce r8873: if pri_protocol is not explicitly set
(in /etc/dahdi/xpp.conf) and the device has (licences for) less than 4
"PRI" (E1/T1) ports, the initialization script will attempt to read from
a non-existing SysFS file, and bail out, resulting in a the device
failing to initialize.
For those non-existing ports we can just skip that part of the
initialization. So we just skip it.
Work around: explicitly set pri_protocol to E1 or T1, as needed.
Xorcom Rev: 8047. Ticket: 1334.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9430 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes a typo recently introduced that was preventing asterisk from
setting the swgains on a channel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9423 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Make explicit what part of the union is being accessed.
(closes issue #15908)
Reported by: ys
Patches:
dahdi-dahdi_echocan_events.diff uploaded by ys (license 281)
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9421 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The bigzaplock was used to prevent changes to all the channels during
masterspan processing while conference parameters were changing. The
master span processing also took a global lock out on the chan_lock to
prevent new channels from being registered or unregistered during
processing. Instead of grabbing both those locks, just changing the
semantics of chan_lock to those of bigzaplock seems to fit the bill and
removes another lock from the driver (and saves ~10 ns on a 2.40 GHz
Xeon in prcocess_masterspan)
chan_lock is a candidate for conversion to RCU but usage in conferencing
(bigzaplock type usage) needs to be audited carefully before conversion.
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@9414 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Very slight performance increase when timertest is running in the
background. Measured at ~10 ns improvement over 10K samples.
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@9413 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
Now 'make -j 5' works the way it's supposed to on multi core machines.
On one test machine build times went from ~33 seconds to ~11 seconds.
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@9409 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'[[' is a bash construct specifically, yet #!/bin/sh is at the top of the
file.
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@9408 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When no hardware spans are configured DAHDI will use a kernel timer in order
provide timing for conferences. This is what dahdi_dummy historically was used
for. When kernel timers are used to provide timing DAHDI can both potentially
slow the rate at which time timer runs and also needs to account for how many
milliseconds of audio are processed for each 'tick' of process_masterspan.
The result is that if you are only using DAHDI for app_meetme, you can change
DAHDI_CHUNKSIZE to 40 (5ms) or 80 (10ms) bytes to reduce overhead since user
space is dealing with chunks of 20ms by default anyway.
NOTE: If you set this, you may still need to comment out the board drivers in
drivers/dahdi/Kbuild since they all do not support operating with a
DAHDI_CHUNKSIZE != 8 currently.
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@9407 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_receive, dahdi_transmit, and dahdi_ec_span are mostly called from
interrupt context anyway, so we can save a few cycles by not saving and
restoring the interrupt flags for every channel.
On one 2.40GHz Xeon test machine, for a span with 24 channels w/o echocan
enabled with ~10000 samples:
Function Avg Before Avg After
======================================
dahdi_receive 2.109 us 1.547 us
dahdi_transmit 3.203 us 2.766 us
dahdi_ec_span 0.416 us 0.454 us
NOTE: The time went up slightly on dahdi_ec_span since I did not have
software echocan enabled and this change calls local_irq_save regardless
in dahdi_ec_span. The slight increase in processing time in this case
is overshadowed by the savings in dahdi_receive and dahdi_transmit. If
echocan was enabled on all the channels there would be a time savings
in that dahdi_ec_span too.
When dahdi_receive/dahdi_transmit are called every millisecond (when
DAHDI_CHUNKSIZE == 8) this saves ~0.1% CPU time for each span.
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@9406 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The voicebus interface constantly uses the same buffers for moving data
to/from the card. A fixed pool has less overhead in this case than
constantly mapping/unmapping the kmem_cache_alloced buffers.
Saves about ~2.608 us for each run of vb_isr on a 2.40 GHz Xeon test
machine.
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@9402 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change was made in revision 8176.
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@9401 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
The voicebus library by default configures the PCI interface to poll the
descriptor ring for available buffers. There are some platforms like
the Intel SG3420P motherboard where this does not appear to be
sufficient. Writing to the transmit demand poll register resolves this
problem on these troublesome platforms. DAHDI-700 DAHDI-702.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9397 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If building within a git repository search the last log message for a
'git-svn-id'. If found, the commit has a corresponding svn revision
number and we will use the SVN-xxx-rxxx revision form. Otherwise use the
output of 'git describe --long --always --tags --dirty=M' as the
version.
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@9396 a0bf4364-ded3-4de4-8d8a-66a801d63aff
