Allows dahdi_cfg to return an error code if a board driver fails it's startup
call for any reason.
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@10379 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Otherwise, if the _dahdi_assign_span call fails, the dahdi_device will never
be removed from the dahdi_devices virtual bus and the board drivers will not
be reloadable.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10331 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I misssed a small typo in r10328 "Extra debugging aids and messages" that
would force any span that supports a hardware preechocan to always fail
assignment with -EFAULT.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10330 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Added dahdi_dev_dbg() macro to print when we don't (yet)
have a span number.
* Added a new debug category: DAHDI_DBG_ASSIGN
* Made sure error return code paths prints helpfull messages
* Promote error messages from INFO to NOTICE
* Change some errno values from EINVAL to EFAULT (internal
errors not caused by user input)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-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@10328 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The test in _check_spanno_and_basechan() was off by one
(used '<' instead of '<=')
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@10327 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10205 "dahdi: Check for master in DAHDI_STARTUP / resolves MeetMe
regression." did not handle the case for the wcb4xxp driver since it
would set DAHDI_FLAG_RUNNING as part of the probe. Therefore, the
DAHDI_STARTUP ioctl was never processed for it, creating a situation
where audio is missing on channels that are conferenced with channels on
the BRI spans.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10304 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* We try very hard to help asterisk understand that we unassign spans.
* Implement disable_span():
- Set span + channels to DAHDI_ALARM_NOTOPEN
- qevent DAHDI_EVENT_REMOVED
* Use disable_span():
- in dahdi_unassign_span() and dahdi_unregister_device()
- with long msleep() so asterisk has a chance to get the message
- Out of the registration_mutex so we actually context switch.
* Also return more POLLERR variants (POLLRDHUP is not portable,
should be tested).
* Also improve printk(), fix rate_limit increment (was missing)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10285 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irqmisses' is more a function of the device and there are better ways
to get to IRQ for a device than storing it in any DAHDI structures.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10276 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This exposes dahdi devices in sysfs and also exposes attributes that
will allow user space to control the registration order in spans. This
facilitates loading drivers out of order yet keeping consistent
span/channel numbering, which in turn will eventually allow the
blacklist for DAHDI drivers to be removed. The default behavior,
controlled with the auto_register module parameter on dahdi is to number
the spans / channels in order like is currently done. So this change
does not introduce any new behavior by default.
* Writing (anything) to this attribute returns the span to its
unassigned state
* Fix dahdi_chan_unreg() echocan refcount
* Add safeguard against duplicate unassignment to _dahdi_unregister_span()
* Remove the span from device_node list, only in dahdi_unregister_device()
and not in dahdi_unregister_span()
* Free allocated span->span_device in span_sysfs_remove()
[is it safe?, didn't cause problem so far...]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi: Add "hardware_id" dahdi_device attribute.
- The "hardware_id" does not change with device location (e.g: when a PCI
card is moved from one slot to another).
- Not all devices have this attribute. It is legal for it to be NULL (that
is the default for all low-level drivers that do not set it explicitly).
- When "hardware_id" is NULL, the sysfs attribute value is "\n"
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10275 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change will facilitate creating rules that will allow spans and channels
to be accessed by named device files instead of by numbers.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10274 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Increasingly, spans are implemented by devices that support more than a
single span. Introduce a 'struct dahdi_device' object which explicitly
contains multiple spans. This will allow a cleaner representation of
spans and devices in sysfs since order of arrival will not determine the
layout of the devices. This also gives the core of dahdi a way to know
the relationship between spans.
This generalizes similar concepts that were previously xpp specific. The
conversion of the xpp code was almost entirely done by Oron and Tzafrir.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10273 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This patch contains interim results while trying to make
device removal work correctly:
* XPP has protections to prevent dahdi unregistration while
channels are open -- they are now removed, so we can
unregister immediately.
* Handle processes in poll_wait():
- Wake them during dahdi_chan_unreg() after the channel
is gone (chan->channo = -1 or chan->file->private_data == NULL)
- Test in every wait_event_interruptible() that the channel
was not gone (chan->file->private_data)
- Return correct values (POLLERR | POLLHUP) instead of
some errno (would be important in the future if we
modify asterisk to respond correctly to this condition.
* Other issues:
- If unregistered channel is being polled, than call msleep() before
returning, to give other processes a chance (normally, asterisk
has RT priority)
- Call close_channel() from dahdi_chan_unreg() so it releases
related tonezone
* There is still a horrible race hidden by msleep(20) in
dahdi_chan_unreg()
force close channels from dahdi_chan_unreg():
* Mark them via DAHDI_FLAGBIT_OPEN
* Call low-level driver close() method if available
* What about other closing activities?
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10270 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There were a couple of reports that MeetMe conferences were not
working in 2.5.0.1 and that downgrading to 2.4.1.2 resolved the
issue. This could occur if there were no analog spans in a system,
and all the digital spans were out of alarm before DAHDI_STARTUP
ioctl was called by dahdi_cfg. If the spans were *not* out of alarm,
they would be marked master when the span changes it's alarm state.
This would result in a condition where no spans were marked as the
"master" and so the core timer was handling conferencing. The core
timer runs by default at 4ms and most board drivers run at 1ms
intervals, but a channel currently only buffers up 2ms of data when
conferenced. Therefore, 2ms of audio from a board was continuously
dropped from the conference every 4ms by default.
This fixes a regression first introduced in 2.5.0 which was
specifically added in revision r9611 "dahdi: Do not locate new
master in interrupt context."
Internal-reference-ID: DAHDI-894
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Tested-by: Dennis Martinez <dmartinez@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI currently waits a second before checking if a board driver is
calling dahdi_receive and switching to internal timing. Some versions of
Asterisk (I was looking at 1.4.42 when writing this) only wait 300ms for
a timer to expire when first starting and verifying that DAHDI is
properly configured. This can result in a
"ERROR[27673] asterisk.c: Asterisk has detected a problem with your DAHDI
configuration and will shutdown for your protection. You have options:"
message if asterisk is started soon after loading DAHDI.
This change sets the inital polling interval to the same as that used
during normal coretimer operation, 4ms. The interval will still be
slowed to 1 second if a board driver starts calling dahdi_receive().
DAHDI-892.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10200 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When attaching software echocans to a channel, if there is a hardware
echocan available always give preference to them.
Revision 9995 "dahdi: Always attach hwec to a channel if available" had
an error where if a driver did not even support an option of hardware
echocan, dahdi-base would take that to mean there always was a hardware
echocan available on the channel.
DAHLIN-246
Reported-by: Michael L. Young
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@10070 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Make sure that the call to dahdi_chan_unreg() in free_pseudo() is
protected by the registration_mutex, like the other calls to that
function.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10056 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If set to true (default) a HWEC, if available on the channel, takes
priority over any software echocan configured in /etc/dahdi/system.conf.
This has historically been the default behavior in all released versions
of DAHDI that support module echocans.
Otherwise, hwec_overrides_swec is set to false, HWEC is chosen only via
the "echocanceller=hwec" directive.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-By: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10036 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In previous releases of DAHDI if dahdi_cfg attached a software echocan
to a channel and a hardware echocan was available, the hardware echocan
would be used instead of the software echocan.
Since the 2.4 branch was created a new feature was merged into
dahdi-linux where it was possible to mix software echocan and hardware
echocan on a channel. This required using "hwec" as the echocan in the
/etc/dahdi/system.conf file so that what was specified in the
configuration file is what was actually used.
This has resulted in users upgrading to the trunk of dahdi without
updating their /etc/dahdi/system.conf file and just suddenly not using
any hardware echocans any longer.
The capability to mix software and hardware echocans on a span will be
revisted when running dahdi_cfg on any preexisting configuration files
doesn't just silently turn off hardware echocan.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9995 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This reverts commit r9891 and is part of two commits to revert all the
timer changes.
Grouping the timer into rates did not allow a timers rate to be changed
after another thread is already blocked on the poll call
The problem that was reported was if a sip call was made to a DAHDI
channel and the sip call was disconnected before answer, the DAHDI
channel would never stop rining.
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@9991 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This reverts commit r9937 and is part of two commits to revert all the timer
changes.
Grouping the timer into rates did not allow a timers rate to be changed after
another thread is already blocked on the poll 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@9990 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
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
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
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
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
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
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
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
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
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
