Trivial reformatting that preps it for some parallelizing the module
loads.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9965 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The card position is only used during startup so we don't need to carry it
around in the strucuture.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9964 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The voicebus cards only support the S110M FXS modules which are based on
the 3215. The module flags member was only used to hold whether we were
dealing with a 3210 or 3215 SLIC, so we can drop it since we always know
we'll have a 3215 based SLIC.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9963 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Cuts down on the overhead of constantly saving and restoring the
interrupt registers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9962 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change gets all the easy places and saves on array dereferences
when we already have the address of the module that we are interested
in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9961 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change is to primarily to clarify that the types are always mutually
exclusive.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9958 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This also allows us to add them to the union with the other module types so
they do not add to the memory usage if there aren't any QRV modules installed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9957 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move the data backing the mostly unused string away from the active
members of 'struct wctdm'.
The location where some of the other members of 'struct wctdm' are initialized
were moved so that wctdm_back_out_gracefully always has a fully formed
structure to work on.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9955 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We can already use the module type to determine presence of a module to
check. This also moves the background polling of the modules until after
the board is completely initialized because the module type may change
while the different types are being probed. This also means that we need
to preset the shadow registers for the FXS because otherwise the shadow
register will not have been read before the first time it's checked for
a power alarm.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9954 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Both limit the amount of junk in the kernel log and also prevent dahdi_cfg
from running indefinitely if there is a module with a hardware problem which
prevents it from completing the startup sequence.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9953 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of increasing system startup speed.
Splitting these two operations facilitate checking if there is a module
present synchronously on driver load from the actual load of the firmware and
configuration of the channels.
This will allow the presence of the VPM module to be flagged on the span
before registration, but load and configuration can happen in the background.
When the modules are eventually loaded via udev, there will be enough time
from the time the drivers are loaded to when dahdi_cfg will run to complete
the firmware load, eliminating the need to block the driver here.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9951 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In my opinion naming the VPM workqueues for each board is not worth the
extra complexity.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9950 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Ensures that a single run of the interrupt service routine is consistent
about whether there are VPMADT032 commands to process or not.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9949 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This message also duplicates what is in the /etc/dahdi/system.conf file
and should only be necessary when troubleshooting problems.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9948 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is trivial cleanup. Fixing up a couple of places that followed a
kmalloc with a memset to 0 and also sneaked in one ARRAY_SIZE usage
change.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9947 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The firmware load of the VPMADT032 was moved to startspan because a
quad-span card in the same system would would lock interrupts for
several seconds to load VPMOCT064/128 firmware. Now that the wct4xxp
driver no longer locks interrupts while loading its VPM module this
driver can move the VPMADT032 check/load back to module load time.
This is also required so that the presence of a hardware echo canceler
is marked on the span before it is registered with dahdi-base.c.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9946 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is always true currently but will not necessarily be in the future.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9945 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Currently the board will always be ready if the module initialization
function is complete but this change will facilitate allowing some of
the more time consuming configuration steps to happen in parallel on
system start.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9944 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This defines a NULL value for the name of an echocan as invalid. This
will allow dahdi_genconf to probe for the presence of a hardware echocan
on a channel by trying to attach one. If there is not a hardware echocan
available DAHDI_ATTACH_ECHOCAN ioctl will return -EINVAL if 'hwec' was
specified as the name of the echo canceler now.
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@9943 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Not quite ideal, but this seems to be the most straightforward way to
know when someone is trying to monitor the preec stream on a channel.
This callback allows the board driver providing the span an opportunity
to setup the hardware preecho monitoring as needed.
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@9942 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_ec_chunk is the function that saves the received audio and places
a signed linear copy of it in the pre echocanceled buffer on the
channel. By splitting the input and output of this function into two
parameters, a driver that can provide separate pre and post ec streams
can pass them independently to DAHDI, without worrying about DAHDI
overwriting a stream that may have already been echocanceled by the
hardware.
Previously, the dahdi_ec_chunk interface took a received audio buffer
and overwrote it after canceling the echo. Now the input and output
from the function are broken up in order to support hardware echocans
that have a different preechocan stream.
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@9941 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change ensures that the dahdi_span_ops callbacks are not called
with any spinlocks held, and that the module is pinned in memory, and
also passes the struct file * pointer to the callbacks.
Passing the file pointer to the callbacks allows the board drivers to
check any flags on the file descriptor used to configure the
span/channel. The intent here is to allow dahdi_config to open the
/dev/dahdi/ctl file in a non-blocking mode in case there is a lengthy
processes that needs to happen as part of configuration.
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@9940 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This allows any echocan cleanup to block if necessary. Especially useful
for hardware echocans that may need to wait for hardware to complete the
cleanup process.
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@9939 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'struct mutex' was introduced in 2.6.16. While DAHDI previously allowed
statically allocated mutexes, this change is required in order to allow
mutexes to be embedded in dynamically allocated structures on older kernels.
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@9938 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Some older Asterisk versions do not handle well the error message when poll is
called on an unconfigured channel. The result would be constant
__ast_read: No/unknown event '0' on timer for 'DAHDI/1-1'?
messages from Asterisk.
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@9937 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This duplicates information that is already in the
/etc/dahdi/system.conf file and should normally only be necessary for
the user when debugging problems.
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@9936 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change fixes a condition where 'dahdi_cfg -s' would always return
success regardless of whether a board driver was able to complete the
shutdown. Only impacts board drivers that implemented the shutdown span
callback.
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@9935 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This allows dahdi-base to know whether or not there is a VPM attached to
the module as soon as it's registered as opposed to waiting for start
span. This will simplify dahdi_genconf's task of creating a valid
configuration file.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9933 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If we always set maintstat to DAHDI_MAINT_NONE, dahdi_base will lose
track of what it thinks the current state of the span is.
For example, if you run
$ dahdi_maint -s 1 --loopback localhost
When t4_clear_maint is called, the current maintenance mode state,
'maintstat', is set to DAHDI_MAINT_NONE. So the next time you call:
$ dahdi_maint -s 1 --loopback off
dahdi-base.c will believe that the user is trying to set the maintenance
state from DAHDI_MAINT_NONE to DAHDI_MAINT_NONE and will not actually do
anything.
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@9932 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Do not allow the interrupt handler or another CPU to change the value
between when we get the initial value and when we write the modified
value.
Also includes a minor formatting fix where braces were not aligned, and
remove 'inline' from t4_framer_in and t4_framer_out definitions.
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@9931 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Turn this option on for the entire wct4xxp driver in order to quiet the
warnings in the oct612x source files. These files are from a vendor drop and
the goal is to limit the deviations from the vendor if possible.
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@9930 a0bf4364-ded3-4de4-8d8a-66a801d63aff
gcc-4.6 now warns about variables that are set but never used. Clean up
unused variables everywhere except the oct612x subdirectory.
The oct612x should go in a separate patch in case that needs to be
pulled out into a separate project again.
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@9929 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Some older Asttribanks had an empty label string. They should be ignored
when testing for a duplicate label at device probe time.
While we're at it, reduce panic level in the notice.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9925 a0bf4364-ded3-4de4-8d8a-66a801d63aff
XPP_DEBUGFS code was some code used to send BRI D-Channel data
through debugfs for, well, debugging. Unused in recent years.
Time to remove.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9917 a0bf4364-ded3-4de4-8d8a-66a801d63aff
OLD_PROC marked old and unused code that was used for writing to procfs.
It has long ago been replaced with different sysfs interfaces. Time
to remove it.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9916 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Commit r9781, "wcte12xp, wctdm24xxp: Remove unused support for booting
VPMADT032 from SPI", introduced a bug that would prevent the VPMADT032
from ever being able to complete its startup. This regression did not
make it to any releases.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9914 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Introduced in rev 9905, this bug could cause buffer events to become
disabled if the kernel was unable to access userland data.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9907 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Add BUFFEVENTS and individual buffer event channel flags so that DAHDI can
notify userspace processes when it is dropping data. This can be useful when
trouble shooting fax problems since DAHDI currently silently discards data
becasuse of scheduling latency. With this change, Asterisk could log an event
as opposed to just leaving it up to the tone detectors to figure out there was
some unexpected phase shift.
Acked-by: Shaun Ruffell <sruffell@digium.com>
(original patch by Matt Fredrickson)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9905 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Alexandre reported that on a particular server he would get a server
crash when loading the wcte12xp driver after receiving a line about a
timeout when trying to read the mode selection jumpers.
If the driver times out when trying to read the mode selection bits
there is a serious problem and it should not try to continue on with
configuration / registration.
Reported-and-Tested-by: Alexandre Abreu <alexandre.abreu@redt.com.br>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9902 a0bf4364-ded3-4de4-8d8a-66a801d63aff
RHEL 5.6 has backported dev_name in include/dahdi/devices.h. We now need to
check for a back ported definition before defining our own version on pre
2.6.26 kernels.
(closes issue #18992)
Reported by: ndupeux, AlexCeli
Tested by: elguero
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@9894 a0bf4364-ded3-4de4-8d8a-66a801d63aff
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
