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
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
If we know that an open file is associated with a channel (pseudo or
real) we can just update the file->f_ops pointer so that we can short
circuit some of the checks in read/write/poll. Trades sizeof(file_operations)
bytes for less function call overhead in the "hot" path.
On a 2.4 GHz Xeon, saves around 150 ns on each read / write.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9386 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since we have the pseudo channels on their own list, we don't need to
step through the chans array when we just want to find the pseudo
channels. Likewise, all the real channels will have be on a span. Also
removes references to the global chans array in process_masterspan.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9384 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since pseudo channels are without spans and we would like to use the
span list to enumerate through all the channels, keeping the psuedo
channels on their own list is required. I believe this is a more
natural choice than making a dummy spans for pseudos since pseudo
channels should *really* just be an implementation detail that the user
shouldn't care about.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9383 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change also involves setting the DAHDI_FLAGBIT_CLOSE bit on the
channel before calling the 'close' callback in span ops. It appears
that only the dynamic spans may delete the channels on close, but that
code path doesn't check the DAHDI_FLAGBIT_CLOSE bit anyway.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9373 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If someone was still using this...feel free to add it back in with a
comment about why it needs to be in the mainline. It looked better to
remove it than edit it to make sure it worked.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9370 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This ioctl is called either via the "/dev/dahdi/channel" file or via a
/dev/dahdi/channo file. In either case, either the minor number of the
device file will match up with a channel, or the "private_data" member
on the channel will be set, so the unit is redundant.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9369 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I believe this makes it a little more clear what is happening. Also could
provide a potential speedup if the span doesn't need to be constantly
dereferenced (although an optimizer might make this moot). Regardless, this
change doesn't hurt.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9362 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In __dahdi_process_getaudio_chunk and __dahdi_process_putaudio_chunk we
can streamline the operation slightly by saving a constant pointer to
the conference channel instead of constantly dereferencing the master
channel and indexing into the chan array.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9361 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It is still used at span registration / unregistration to assign the span
number, and when iterating through all spans. Otherwise, moves the code base a
step closer to removal of the 'spans' array.
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9355 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Enable DAHDI to detect if an operation on a file handle refers to a
channel that may have been unregistered. This can occur, for example,
when a board driver is hot-swapped out in a live system.
This patch ensures that file->private_data is always properly set for
any open channel, and it's set back to NULL when a channel is
unregistered. This way file->private_data can be used to check whether
it's valid to perform an operation on the channel. (NOTE: There is
still a race condition here if the driver was unbound on one processor
during the window of time between when file->private_data was checked
and the system call finishes).
Also, since DAHDI should only return -ENODEV on read or write when there
was a surprise device removal on a running system this sleep can prevent
the system from becoming unresponsive if the userspace application does
not check for the -ENODEV error and constantly tries to call read with
elevated privileges.
(issue #17669)
Reported by: tzafrir
Tested by: sruffell
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9353 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Most likely some stale debugging code that slipped in and is now gone.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9350 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Makes it a little more clear what the '0' parameter represents.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9324 a0bf4364-ded3-4de4-8d8a-66a801d63aff
These functions were only defined if BUF_MUNGE was defined, but even if
that symbol is defined there is not anyplace in the driver where these
functions were then called. This has been in the code since rev 87 so
this is most likely stale debugging code.
Feel free to revert if this is actually used somewhere that is not
apparent.
Here is where the functions were originally added to the drivers:
http://svnview.digium.com/svn/zaptel?view=revision&revision=87
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9322 a0bf4364-ded3-4de4-8d8a-66a801d63aff
These label parameters were not used in the functions. They are most
likely some debug code that was left over.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9321 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Put the "Master changed to xxx/x/x" message behind a debug flag. It's an
implementation specific detail and has caused confusion with customers.
DAHDI-692
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9299 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Kernel interface for network devices changed. This is the patch from issue
plus a few trivial checkpatch.pl formatting changes (minus the >80 column
warnings).
(closes issue #17857)
Reported by: msink
Patches:
dahdi_net-v2.patch uploaded by msink (license 1103)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9247 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There are not any existing users of the interface (and it would always
return -ENOSYS to the caller anyway).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9246 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
