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
If dahdi_register fails, we would like the error to propagate to the
user who ran modprobe.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9636 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Extended reset is needed primarily with the PCI express version of the
dual and quad-span cards. Enable it by default for those cards and
allow it to be forced on or off globally for the driver as a compile
time option.
The options to force it should be able to come out if there aren't any
further reports that the compile time option needs to be set.
DAHDI-773
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9635 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Now that makefw has the proper name, the rule to create it is
automatically generated by Kbuild. Removed.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9632 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If we tell Kbuild (at least of some versions) that the host program is
$obj/makefw , it will attempt to create the full path of $(obj) for it
under the current $(obj).
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9630 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
Since the return value is not defined/used just return void.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9587 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
2.6.25 added the DEFINE_PCI_DEVICE_TABLE macro to make sure that the
pci_device_id tables are put into the correct section in the binary.
Convert all the places where the tables were defined to use them.
This is linux-2.6 commit where the change went in along with the
rationale: 90a1ba0c5e39eeea278f263c28ae02166c5911c8
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@9584 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
Some spans, specifically dynamic local spans, should never be the timing
master since they are dependent on some other timing source driving
them.
The bit in 'struct dahdi_span' is named cannot provide timing so that by
default the other drivers will set it to 0.
This is loosely related to issue #13205 but doesn't address any of the
other elements of that issue about how to allow the user to configure
what the master span order of succession is.
(issue #13205)
Reported by: biohumanoid
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@9581 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Also makes it safe to unregister a dynamic driver when there aren't any
open channels on the dynamic 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@9580 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This allows the pvt member to be set under lock without holding the lock
through the call to create destroy.
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@9578 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Running in tasklets does not work well when dahdi doesn't have a span that is
acting as the master. In this case, process_masterspan is being called in
system timer that may not be running at 1ms intervals. The end result is that
the dynamic_run function isn't called for every chunk processed, and there is
data loss.
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@9577 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Dynamic spans that are unable to provide their own timing, like dahdi
local spans, typically derived their timing source from
dahdi_dynamic_ioctl(0,0) call in process_masterspan.
This change uses the sync_tick member of dahdi_span_ops instead so that
dynamic operations do not happen on a span until it is fully registered.
Also removes the check for dahdi_dynamic_ioctl in process masterspan for
those users that never load a dynamic span.
This was originally suggested in a comment on:
(issue #13205)
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@9576 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2.6.9 is the earliest kernel version currently supported by 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@9575 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move the try_module_get/module_put calls from the various dynamic
drivers into the "core" dahdi_dynamic.c file itself. This way, a
reference count can always be held while calling through the function
pointers. This is enabled by adding an .owner field to 'struct
dahdi_dynamic_driver'.
Dynamic spans are also unique in dahdi in that they require a "dahdi_cfg
-s" to stop them and release the references on the modules. This is
counterintuitive. This change makes sure they are reference counted just
like other spans and on driver unload, if there aren't any open handles
from userspace, they will take care of unwinding themselves.
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@9573 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_dynamic can be converted to use kernel idiomatic reference
counting since DAHDI only supports 2.6.9+ kernels now.
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@9571 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The return value from the transmit callback function was not used
anywhere, and is now removed.
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@9570 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Replaces all the 'z' references to 'd' as appropriate and cleans up any
formatting problems that popped up as a result. The intent here is to
reduce confusion in the future as someone may wonder what the 'Z's refer
to.
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@9567 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It's possible for dahdi_dynamic_loc spans to be "peered" before the
dahdi_span is fully register. Do not call dahdi_dynamic_receive on any
peers before they are fully registered.
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@9566 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a trivial formatting change in order to not introduce any warnings.
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@9565 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The memory saved by using a singly linked list does not, in my opinion,
outweigh the benefit of using the standard kernel macros.
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@9564 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Hopefully will eliminate any questions about what the 'z's are supposed
to represent.
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@9562 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This file is now in drivers/dahdi/voicebus folder. This file should
have been removed when the Gpak API was moved out of the individual
board drivers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9559 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a very slight performance improvement. Eliminating the need to
save the IRQ flags is probably more of a boost than grabbing and
releasing the reglock.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9558 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Mostly linux/errno.h was included more than once.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9557 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi/wcb4xxp driver used with Digium Wildcard B410 quad-BRI PCI card
unable to communicate with another ISDN device (ISDN phone, another port
of B410). It appears that B-channels are capable to transport data, but
D-channel is not.
Debug output added into the driver shows that packets are transmitted to
the D-channel, but no packets are received. Further investigation shows
that no interrupts received from Rx FIFO associated with D-channel,
although packets are delivered to the FIFO. I've found that problem is
in improper usage of chan->chanpos while indexing the fifo index
(bspan->fifos): chanpos starts from 1 and fifos starts from 0.
Therefore, garbage read instead of fifo number.
(closes issue #14834)
Reported by: vvv
Patches:
dahdi-linux-complete-2.2.0-rc1.patch uploaded by vvv (license 741)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9555 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Instead of using pci_set_drvdata embed the 'struct voicebus_operations'
directly in the context so we can use container_of to find the context.
This resolves a problem where the 'remove_one' callback gets an invalid
pointer to 'struct t1' if the VPMADT032 is in the middle of a reload
when the module is unloading. DAHDI-783.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9554 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is instead of initializing the waitq each time the channel is
opened or closed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerreicks <rmeyerreicks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9549 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since we've now switched to wait_event_interruptible calls, we have a
condition that we can check when we're awoken. This allows us to
combine the separate wait queues into a single queue.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerreicks <rmeyerreicks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9548 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Makes it a little more clear what it is we're really waiting for.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerreicks <rmeyerreicks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9547 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a cleanup patch to make it a little easier to see what the bits
mean.
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@9543 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There are some platforms where the read-line multiple transaction causes
packets to be dropped in the voicebus pipeline. The only observable
behavior is that packets just go "missing" in the pipeline. This also
only appears to affect PCI cards.
A typical 'symptom' of this problem is you may see IRQ misses increasing
without any corresponding "bumps" in latency in the kernel message log.
Normally, IRQ misses are correlated to latency bumps since that is an
indication that the host was not able to service the card interrupt in a
timely fashion. DAHDI-510 DAHDI-774
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9542 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The 'pdev' member already contained a pointer to what 'dev' was pointing
to. Also ensure most of the changed lines are under 80 characters.
There are two lines that are were too deeply nested to do anything
sensible.
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@9540 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rwlock is slower than normal spinlocks and this lock is rarely contended
for. Also noticed that the vpmadt032_module_init function is now (was
already) redundant since all the elements initialized in it were already
initialized.
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@9538 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The mode module parameter is only acted on during module initialization.
We shouldn't allow anyone to change it after the driver is already
loaded.
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@9537 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Span registration is the last step in during initialization and it
should be the first on unregistration. I also was hit by this when
looking at adding other members to the span and made the assumption that
the span was in a consistent state during unregistration.
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@9536 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This reduces the chance that another interrupt will interfere with the
recovery process. Otherwise it is possible that the hardware advances
past the position that we think it is currently at.
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@9535 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Reading 0xffffffff from the registers is a different error than just not
coming out of reset. Add a little extra debugging information.
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@9534 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes a regression introduced in r9510 which saves a pointer to the ops
member of a channel's span before checking if the channel is a pseudo.
Psuedo channels do not have spans.
(issue #18463)
(issue #18422)
Reported by: alecdavis
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9530 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I apparently forgot all about HPEC when updating the echocans for the change
in the factory and echocan ops structures related to echocan naming. The HPEC
wrapper should now be up to date with the rest of DAHDI.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9526 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Changed the echocan factory name to a function (get_name) called to get the
name. This allows a factory to return a different name when being called in
reference to a channel such as in the case of hardware echo cancellers. To
further accommodate this change for HWEC, a new echocan_name function was
added to the span ops struct and is used in hwec_factory in dahdi-base for
all cards that support hardware echo cancellation.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9524 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This field was redundant and was only used in places where the factory's name could be used.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9523 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Remove the code that allowed hardware echo cancellation to automatically
override software cancellation and prevented SWEC from working at all on a
card if HWEC was installed. All EC now uses the standard modular EC interface.
Additionally, the "SWEC" identifier on channel lines in /proc/dahdi has been
changed to "ECTYPE" to avoid confusion.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9521 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change adds an echocan factory to dahdi-base that will allow hardware
echo cancellation to use the same interface as the current software echo
cancellers. The additions in this commit will not have any effect until the
current HWEC mechanism is removed.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9520 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The loopup/loopdown T1 maintenance feature in the single through quad-span
drivers now function properly, according to AT&T TR54016, by sending a
full rate pattern down the line. T1.403 ESF/Data Link patterns are not
supported currently.
Also grouped all the maint reset register clears under a single irq lock
to crank the performance up past 11.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9516 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI_MAINT_LOOPSTOP is being removed due to the redundancy with
DAHDI_MAINT_NONE. Also removing some timing logic, as amount of time a
loopup or loopdown signal is held on the line, is now defined in
userspace with dahdi_maint.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9515 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The dahdi_span->maintq wait queue was very old and not being used so it
has been removed.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@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@9514 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The wcte12xp does all the checking for alarm in a user space workqueue.
Most of this time is spent sleeping waiting for reads from the framer to
complete. Tasks in uninterruptible sleeps are added to running tasks
for the purposes of calculating load average. This change makes the
sleeps interruptible so as to not affect the load average as much.
For example, the following command will load and configure the driver and
then print the load average every 10 seconds.
]# modprobe wcte12xp && dahdi_cfg && ((x=12)); while [[ $x -gt 0 ]]; do cat
/proc/loadavg; sleep 10; let x=$x-1; done
With this change:
0.29 0.10 0.02 1/101 29945
0.24 0.10 0.02 1/101 29967
0.20 0.09 0.02 1/101 30019
0.17 0.09 0.02 1/101 30041
0.15 0.09 0.02 1/101 30062
0.12 0.08 0.02 1/101 30085
0.10 0.08 0.02 1/101 30107
0.09 0.08 0.02 1/101 30129
0.07 0.08 0.02 1/101 30151
0.14 0.09 0.02 1/101 30173
0.12 0.09 0.02 1/101 30195
0.10 0.08 0.02 1/101 30217
(and I've seen it get down to 0.0)
Before this change:
0.57 0.22 0.07 1/101 31920
0.48 0.21 0.07 1/101 31942
0.48 0.22 0.07 1/101 31964
0.48 0.23 0.08 1/101 31986
0.41 0.22 0.07 1/101 32008
0.42 0.23 0.08 1/101 32030
0.43 0.24 0.08 1/101 32054
0.45 0.25 0.09 1/101 32076
0.45 0.25 0.09 1/101 32098
0.46 0.26 0.10 1/101 32120
0.47 0.27 0.10 1/101 32172
0.39 0.26 0.10 1/101 32194
(closes issue #18142)
Reported by: foxfire
Tested by: foxfire
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9512 a0bf4364-ded3-4de4-8d8a-66a801d63aff
