Most of the timers added to the kernel will be configured to fire at the
same rate. This allows one "wake_up" from interrupt context to wake up
all the waiters. On one test system, I saw about a ~10% improvement in
CPU utilization when 10,000 timers were opened.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9891 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since cli/sti are expensive instructions, if the board drivers are
calling receive/transmit/ec_span from interrupt context all local
interrupts do not need to be disabled. The board drivers all still use
the normal dahdi_receive and dahdi_transmit. _dahdi_receive and
_dahdi_transmit are the "in-hardirq" versions of those functions.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9884 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes regression introduced in r9603 where if a channel was "dacs" with
another interrupts would be reenabled prematurely.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9878 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the clock shifts back, don't hang in a loop of running
process_masterspan from the timer interrupt forever.
Fixes a regression of r9407.
(closes issue #19035)
Reported by: tzafrir
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
After talking with Tzafrir on IRC, I combined the check if your far ahead
with the check if you're behind and added a '\n' at the end of the
existing "detected time shift" message. That is why this patch is
different than what is posted on issue #19035.
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9876 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This moves the version string into dahdi-version.c that is then linked into
dahdi-base.c and dahdi-sysfs.c. This speeds builds on slow computers since
dahdi-base.c and dahdi-sysfs.c does not need to be rebuilt if only the version
string is changing.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9777 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Switch to using the newer seq_file interface for procfs. Fixes a
race when you read the "file" while its size increases (e.g. the span
enters an alarm state).
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(closes issue #18760)
Patches:
0001-DAHDI-linux-trunk-replace-old-proc-interface-by-mode.patch uploaded by tzafrir (license 46)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9770 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes a regression introduced in r9611. Analog spans would never become
the master since the SPANSTART ioctl is not typically called on them,
and therefore they were never marked RUNNING. The result could be audio
problems.
I'm marking this as related to issue 13205 since it's generally all
related to how should the drivers select which span is the master. I
also mark as related to issue 16165 because the problems experienced are
a result of the same fundamental issue.
(issue #13205)(issue #16165)
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@9729 a0bf4364-ded3-4de4-8d8a-66a801d63aff
With the release of Linux 2.6.37, the Big Kernel Lock is now a compile
time option. This change adds a mutex around the one place in the code
that we already knew was dependent on the lock_kernel/unlock_kernel
calls for serialization and drops the other calls to
lock_kernel/unlock_kernel if CONFIG_BKL is not defined.
This is *mostly* the dahdi-no-bkl.patch with a few minor whitespace
changes, the global_dialparmslock made static, and a warning added to
let people know they are running an experimental configuration.
(issue #18604)
Reported by: jkroon
Patches:
dahdi-no-bkl.patch uploaded by jkroon (license 714)
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9721 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Just clarifying a parameter that is never updated.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9644 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move the description of the master span processing to above the
process_masterspan function.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9643 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes a regression introduced in r9603. That commit removed
DAHDI_CONF_DIGITALMON handling (which is used to natively bridge two
channels that cannot be crossed in the board driver / hardware) since I
mistakenly thought that it was only part of the DACS handling. The
symptom of the regression is muted audio when Asterisk tries to natively
bridge two channels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9642 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move pseudo channel numbers up into a high range so that their presence
does not interfere with assigning channel numbers for the channels
implemented on spans. Otherwise, if a pseudo channel was opened up
before an expected span was registered, all the channel numbers in the
newly registered span would be bumped up one. This does limit the number
of real channels that a single system may have registered to 32K (but in
dahdi-linux 2.4.0 and below you were limited to 1024 channels anyway,
both real and pseudo).
Also, the string name of the Pseudo channel is now based off the
number of Pseudo channels and not the total number of channels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9637 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Refactor SysFS and device-related code to drivers/dahdi/dahdi-sysfs.c .
* Move common headers to drivers/dahdi/dahdi.h .
This commit merely moves existing code and should have no functional
change.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9628 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Separate out device generation in dahdi_[un]register to separate
functions.
* As we don't keep anywhere the information of whether or not
* there's
an existing device node for a channel, I abuse an unused flag:
DAHDI_FLAGBIT_DEVFILE (25), to mark if the channel has a sysfs node.
DAHDI_FLAGBIT_DEVFILE is expected to be replaced later on with a proper
pointer to the device (or embedding of the device). I prefer a simple
flag for now as it does not break ABI.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9625 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Separate out device initialization and removal functions:
dahdi_sysfs_init() and dahdi_sysfs_exit(). A safer way of
generating the main device files.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9623 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_check_conf() acqurires the locks as needed when scanning the
channels and should not be called under any spinlocks.
Fixes a regression that Tzafrir reported in #asterisk-dev that he could
trigger via "asterisk -rx 'channel originate Local/600@demo
Application Meetme 3000,d'"
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@9621 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes a regression from r9609 that Tzafrir reported. If you
register multiple spans, then remove the first span and try to register
a new span with more channels then the old span, you could end up with
multiple channels with the same number.
This change ensures that spans are ordered and that channels on a span
are always contiguous and ordered in relation to the spans.
In previous released versions of DAHDI (2.4.0 and below) this condition
would result in spans that may not have contiguous blocks of channels.
So it fixes both a recent regression and improves the behavior.
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@9617 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The default tone lengths are compile time options and they were in
digits.h to make it easy for users to patch. Most of these settings are
potentially overridden from user space via the DAHDI_SET_DIALPARAMS
ioctl currently regardless of these settings.
In r9597 I moved digits.h directly into dahdi-base.c since I thought it
was broken out for sharing between compilation units as opposed to
ease patching.
I also changed the units of the default options to ms instead of in
samples. This way if the sampling frequency changes the user will not
need to update the defaults.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
asterisk-dev-reference: 4D236FD7.30707@digium.com
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9616 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a cleanup as part of simplifying reference counting for the
spans.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9612 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When a span goes into alarm it will look for a potential new master
span. For dynamic spans that are running their processing in the
sync_tick callback, the chan_lock will already be held. Therefore,
push the locating of a new master out to the global workqueue.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9611 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since there isn't a fixed array to hold all the channels, and also limit
the total number of channels that can be created, we'll add a module
parameter to allow the system administrator to specify the maximum
number of pseudo channels. This is to prevent a potentially
non-privledged process from consuming too much CPU (since all pseudos
are checked each "tick" for conferencing) and kernel memory.
By default the number of pseudo channels is limited to 512. Change the
default limit with:
]# modprobe dahdi max_pseudo_channels=<new limit>
or at runtime with:
]# echo <new limit> > /sys/module/dahdi/parameters/max_psuedo_channels
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9610 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Remove the remaining locations the 'chans' array was referenced but keep
the observable behavior the same. Namely, channels are numbered in
registration order. Only now it's possible to renumber channels easily
since their number is not also their implied location in the 'chans'
array.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9609 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In dahdi_chec_conf, dahdi_chan_unreg, and dahdi_ioctl_confdiag maxchans
and DAHDI_MAX_CHANNELS was used to scan through all the channels. Since
the channels are stored on the list of spans and list of pseudo
channels, we can directly iterate through those lists. This also paves
the way for removing the arbitrary limit on the number of channels in
the driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9608 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of getting rid of global chans array. We need to search the list
of spans and the list of pseudo channels. While this is slower than a
direct index into a 'chans' array, the places where this function is
called are not in the 'hot' path but instead part of channel
configuration and conferencing setup.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9607 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Streamlines the function a bit by grouping the three conditions that
would cause the channel receive to be completely skipped.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9606 a0bf4364-ded3-4de4-8d8a-66a801d63aff
IMO this improves readability of dahdi_receive and dahdi_transmit, and
the compiler can decide if it is better to inline this in with the
caller or break it out into a separate function.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9605 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When we're in monitor mode, we can save a pointer to the channel we are
monitoring directly instead of dereferencing the 'chans' array each
time.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9604 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This both removes the need to reference the 'chans'
__dahdi_process_putaudio_chunk and __dahdi_process_getaudio_chunk, and
allows the dahdi_receive / dahdi_transmit logic to be streamlined. DACS
channels can no longer be echocanceled if crossed. However, if a
channel was DACSed with dahi_cfg it couldn't have been echocanceled
anyway since the echo cancelers are disabled on the channel by default.
This change was originally contained in a patch kpfleming had floating
around. I split it up and merged it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9603 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There is no need to check the flag on the master channel when processing all
the slave channels. Originally part of a patch kpfleming had floating around.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9602 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Eliminates the need to look for the channel number twice.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9599 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Spans are no longer added to a static array, but they are chained
together in a list. DAHDI_MAX_SPANS, while no longer used in the
kernel, is still in include/dahdi/user.h since dahdi tools is currently
using it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9598 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Clarify that these definitions are not / no longer used outside
dahdi-base.c.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9597 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Mainly I wanted to document that the global_dialparams is protected by
the BKL so that it can be closely checked when lock_kernel is removed
from DAHDI.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9596 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change primarily is a memory reduction. Most users only ever have
a single tone zone loaded so we can save some mostly unused pointers by
using a list instead of an array. Since we also have a pointer to the
dahdi_zone in struct dahdi_chan, we also don't need to store the integer
that is an index into that array. This saves 4 bytes for every channel
allocated in the system. Finally, we don't need a separate default_zone
member since we're on a list, we can define the first element on
the list to always be the default zone.
Additionally, all reference counted structures in the drivers should
standardize on kref as much as possible for simplicity.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9594 a0bf4364-ded3-4de4-8d8a-66a801d63aff
kasprintf will be used in upcoming changes and it's not supported on
RHEL4 kernels. This change essentially backports it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9593 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Might help when someone wonders why they are now getting errors about
"lock_kernel" being undefined.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9592 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Not only should you not reach that line, it's impossible for you to
reach that line.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9591 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Do not allocate the structure with GFP_KERNEL under the lock in
dahdi_echocan_factory_register and closes a leak in
dahdi_echocan_factory_unregister.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9590 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rwlocks are slowly being deprecated because they typically do not
provide the performance increase expected. Most of the
ecfactory_list_lock acquiring is during setup and not in the hot path
anyway, so we can just use the simpler spinlock semantics without the
overhead of a semaphore or mutex.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9589 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rwlocks are deprecated and there aren't that many places where read_lock
was called on the lock anyway.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9588 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a trivial cleanup to primarily to remove the #ifdef test out of
process_masterspan.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9586 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There is already a safe string copying function in all the kernels DAHDI
currently supports.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9585 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Normally, spans are accessed via channels, which increment the reference
count on the supporting module as part of the open call. When operating
on spans by number we are susceptible to a module_unload while we are
accessing the span.
Renames find_span to span_find_and_get to indicate that we're both
finding the span by number and increasing the reference count on the
span. Spans themselves don't currently have reference counts, but we
can increment the reference count on the module that owns the spans.
This will prevent the module that has the span from unloading in the
middle of a span_config call, which in the case of the wcte12xp can take
awhile since the VPM firmware is loading.
Hopefully in the near future the spans themselves will be reference
counted directly.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9583 a0bf4364-ded3-4de4-8d8a-66a801d63aff
