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
