Age | Commit message (Collapse) | Author |
|
Reduce the stack usage by replacing the mOCT6100_RETRIEVE_NLP_CONF_DWORD
and mOCT6100_SAVE_NLP_CONF_DWORD macros with functions. Some compilers
do a better job of optimizing the local variables declared in those
macros than others.
For example, with gcc 4.3.0, running
]# make stackcheck | grep Oct6100 | head -n 20 | sed -e 's/^0\S* //g' | uniq
Before:
Oct6100ApiWriteVqeNlpMemory [wct4xxp]: 1112
Oct6100ApiInvalidateChanPlayoutStructs [wct4xxp]:520
Oct6100ApiSetChannelLevelControl [wct4xxp]: 392
Oct6100ApiBridgeEventRemove [wct4xxp]: 344
Oct6100ApiDebugChannelOpen [wct4xxp]: 312
Oct6100ApiWriteVqeAfMemory [wct4xxp]: 296
Oct6100ApiSetChannelTailConfiguration [wct4xxp]:264
Oct6100ApiRandomMemoryWrite [wct4xxp]: 248
Oct6100ApiTransferToneEvents [wct4xxp]: 248
Oct6100ApiModifyChannelStructs [wct4xxp]: 232
After:
Oct6100ApiBridgeEventRemove [wct4xxp]: 344
Oct6100ApiDebugChannelOpen [wct4xxp]: 312
Oct6100ApiRandomMemoryWrite [wct4xxp]: 248
Oct6100ApiTransferToneEvents [wct4xxp]: 248
Oct6100ApiInvalidateChanPlayoutStructs [wct4xxp]:248
Oct6100ApiModifyChannelStructs [wct4xxp]: 232
Oct6100ApiBridgeRemoveParticipantFromChannel [wct4xxp]:216
Oct6100ApiWriteVqeNlpMemory [wct4xxp]: 200
Oct6100ApiInitChannels [wct4xxp]: 168
Oct6100ApiProgramNLP [wct4xxp]: 168
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9751
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9754 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This saves ~300K of kernel memory for each quad or dual span VPM. Due
to the fact that this change disables caching of the NLP words (among
other things), the time to disable the echocans appears to have
increased by ~1ms.
Before this change:
=======================================================================
0) ! 356.498 us | vpm450m_setecmode(); <--- disable
0) ! 387.762 us | vpm450m_setecmode(); <--- enable
0) ! 429.839 us | vpm450m_setecmode(); <--- disable
]# echo 1 > /proc/sys/vm/drop_caches && free -k
total used free shared buffers cached
Mem: 2005352 228368 1776984 0 132
5540
-/+ buffers/cache: 222696 1782656
Swap: 983036 0 983036
After this change:
=======================================================================
0) ! 1109.515 us | vpm450m_setecmode(); <--- disable
0) ! 339.017 us | vpm450m_setecmode(); <--- enable
0) ! 1431.460 us | vpm450m_setecmode(); <--- disable
]# echo 1 > /proc/sys/vm/drop_caches && free -k
total used free shared buffers cached
Mem: 2005352 228080 1777272 0 112
5484
-/+ buffers/cache: 222484 1782868
Swap: 983036 0 983036
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9750
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9753 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9721
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9725 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The VPM100 and S100M modules are no longer supported. Analog cards supported
by the wctdm24xxp are still compatible with the S110 and VPMADT032 modules.
DAHDI-302
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9720
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9724 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
card in system.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9702 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9635
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9695 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9592
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9693 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
'open' and 'close' were already empty. 't1xxp_shutdown' only cleared
DAHDI_FLAGBIT_RUNNING which is already done in dahdi-base.c after calling
shutdown.
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9318
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9692 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9584
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9691 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9555
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9689 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9554
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9688 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9542
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9687 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9539
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9686 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9535
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9685 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9534
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9684 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9512
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If chan->span->ops->open() fails then the reference count of the module
implementing the board driver will not be decremented. The result is a
module that would always be "in use" and unloadable.
This change makes sure to release that reference when open failed.
(closes issue #18422)
Reported by: avarvit
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Angelos Varvitsiotis <avarvit@admin.grnet.gr>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9510
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9682 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If the span reports that it supports hooksig, DAHDI may fail to use RBS.
So remove a call to that stub function.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9506
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9680 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This fixes an annoying, though harmless issue: if Asterisk decides to send
voicemail messages to a channel (CAS, configured as FXS), We can't do
anything useful with them. So ignore them to avoid scary-looking messages
(from report_bad_ioctl()).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9505
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9679 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
There were some routes through the failure paths in __voicebus_init() where a
registered memory region was not subsequently released. This change closes
those paths.
The result would be on subsequent loads of the driver after hitting the
failure condition you would see "IO Registers are in use by another module."
in dmesg.
request_mem_region/release_mem_region should most likely be converted to
devm_request_region and devm_release_region introduced in 2.6.20
(commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759) which was introduced for
reasons just such as this.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9503
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9678 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Using semaphores as mutexes was removed from the kernel in 4882720b267b.
Just use straight semaphores now. 'DECLARE_MUTEX()' -> 'DEFINE_SEMAPHORE()'
and 'init_MUTEX()' -> 'sema_init()'.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
LKML-Reference: <20100907125057.562399240@linutronix.de>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9464
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9676 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fixes a regression introduced in revision 5916 where FXS modules based
on the 3210 were not properly detected.
(closes issue #18184)
Reported by: bsexton
Patches:
dahdi-fxo-detect.diff uploaded by bsexton (license 1133)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9456
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9675 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
In zaptel commit 4096 [1], all the debouncing of ring signals were moved
into software as opposed to using the ring validation circuit in DAA.
That commit failed to remove the initial check and set of the ring
validation circuit.
[1] http://svn.digium.com/view/zaptel?view=revision&revision=4096
(closes issue #16894)
Reported by: rde42
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9441
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9674 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
It appears that in Centos 4, the version of tar doesn't like the -o
flag, but will honor the --no-same-owner flag.
(closes issue #16063)
Reported by: tzafrir
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9434
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9673 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The voicebus library by default configures the PCI interface to poll the
descriptor ring for available buffers. There are some platforms like
the Intel SG3420P motherboard where this does not appear to be
sufficient. Writing to the transmit demand poll register resolves this
problem on these troublesome platforms. DAHDI-700 DAHDI-702.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9397
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9672 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The registers on the device are already accessed with readl/writel and
the readchunk and writechunk are mapped into coherent DMA region. The
contents of those buffers should not be changing in the middle of any
transmit/receive prep call.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9400
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9671 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
It is possible to softlock if the board stops delivering interrupts in
the middle of a reset.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9332
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9668 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Setting this configuration option would not have had any impact when a
hardware echo canceler was in use.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9432
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9667 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fixes a regression singce r8873: if pri_protocol is not explicitly set
(in /etc/dahdi/xpp.conf) and the device has (licences for) less than 4
"PRI" (E1/T1) ports, the initialization script will attempt to read from
a non-existing SysFS file, and bail out, resulting in a the device
failing to initialize.
For those non-existing ports we can just skip that part of the
initialization. So we just skip it.
Work around: explicitly set pri_protocol to E1 or T1, as needed.
Xorcom Rev: 8047. Ticket: 1334.
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9430
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9666 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Make explicit what part of the union is being accessed.
(closes issue #15908)
Reported by: ys
Patches:
dahdi-dahdi_echocan_events.diff uploaded by ys (license 281)
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9421
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9665 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
(closes issue #15927)
Reported by: Max Khon
Patches:
dahdi_echocan2.diff uploaded by Max Khon (license 884)
void2.diff uploaded by Max Khon (license 884)
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9420
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9664 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This module parameter will allow patgen/pattest to be used only on FXO
ports. *ALL* FXO ports will be placed in digital loopback mode when
set.
The current intent is for this to be removed as an optional module
parameter when there is a channel by channel representation in sysfs.
Otherwise, a new IOCTL would have to be defined and a tool written in
order to support this. DAHDI-696.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9391
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9663 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Enable DAHDI to detect if an operation on a file handle refers to a
channel that may have been unregistered. This can occur, for example,
when a board driver is hot-swapped out in a live system.
This patch ensures that file->private_data is always properly set for
any open channel, and it's set back to NULL when a channel is
unregistered. This way file->private_data can be used to check whether
it's valid to perform an operation on the channel. (NOTE: There is
still a race condition here if the driver was unbound on one processor
during the window of time between when file->private_data was checked
and the system call finishes).
Also, since DAHDI should only return -ENODEV on read or write when there
was a surprise device removal on a running system this sleep can prevent
the system from becoming unresponsive if the userspace application does
not check for the -ENODEV error and constantly tries to call read with
elevated privileges.
(issue #17669)
Reported by: tzafrir
Tested by: sruffell
Review: https://reviewboard.asterisk.org/r/905/
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9353
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9662 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
I have yet to personally come across a system where this actually
changes the observable behavior, but it certainly seems like the sane
thing to do and I would rather not let this float around as a patch when
I can just merge it in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9326
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9661 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
These three bits are already set by 'pci_enable_device' and
'pci_set_master' calls.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9325
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9660 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9317
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9659 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fix the same issue as in r8550 for dahdi_dummy.c
(closes issue #17959)
Reported by: glen201
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9307
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9658 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Upon shutdown, both drivers would attempt to power down external
interfaces, but never attempted to bring them back up when the span was
restarted. Removing that code allows the driver to work properly until
a better solution can be found.
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9316
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9657 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Kernel interface for network devices changed. This is the patch from issue
plus a few trivial checkpatch.pl formatting changes (minus the >80 column
warnings).
(closes issue #17857)
Reported by: msink
Patches:
dahdi_net-v2.patch uploaded by msink (license 1103)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9247
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9655 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
dahdi_tool was incorrectly reporting all spans to be in local timing
mode. This is because the driver tracks which span it's timing syncs to,
within the card local struct "wc". We have to manually go through and
copy timing updates to the span local structs because this is what
dahdi_tool actually reads.
dahdi-526
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9312
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9654 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This needs some more testing before it's on by default. If the card is
otherwise functioning, these messages may be confusing to the user. If
the card is not functioning, the driver can be reloaded with debug to
check for this condition.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The transmit line open detection was pretty weak in that it trips upon
receiving 32 consecutive zeroes. We were getting false positives from
looping and other miscellaneous functions. Removing this feature, but
leaving the transmit line short detector as it actually detects physical
shorts.
From: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9204 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
For kernels >= 2.6.18, each individual card has it's local
timing hung off the pci device in the sysfs tree. dahdi-626
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9188 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This removes a confusing message introduced in 9120 when bridging channels on
two differnt cards. i.e.
"dahdi: unable to cross connect 'TE4/0/2/2' with 'WCTDM/0/0'"
"dahdi: unable to cross connect 'WCTDM/0/0' with 'TE4/0/2/2'"
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9168 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Older kernels do not like the 'bool' type and I cannot just add it into
include/dahdi/kernel.h without compile messages in the xpp driver where bool
is defined directly. Since the wctdm24xxp driver is the only place using that
function, I just moved it back there for now. This fixes a regression
introduced in 9130.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9167 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
DAHDI-681.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9145 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Add compile time option to improve the reference signal provided to
software echo cancelers. The intent here is for this functionality to
become the default behavior but more testing and work on the edge cases
is needed. It's being brought in now as a compile time option since there
have been reports that it helps in some environments.
Instead of using two buffers, which means that at best we're two
milliseconds behind, use a circular buffer where audio data is written
on the transmit side and read on the receive path. In this way high
latency values will not interfere with the operation of software
echo cancelers. DAHDI-291. DAHDI-387.
This work was originally on:
http://svn.asterisk.org/svn/dahdi/linux/team/sruffell/improved_ecreference@9143
and includes a generic kfifo replacement by Matt Fredrickson.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9144 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fixes a regression from 9101 'wctdm24xxp: Added "auto" companding option'
where the analog modules were not defaulted to alaw properly when a
digital module is on an Hx8. This could result in very poor audio since the
modules were providing ulaw data, but dahdi-base believed the audio was in
alaw when converting to signed linear.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9143 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
More work to kill the BKL (Big Kernel Lock)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=10041d2d14688e207d0d829095147aa82c1f211b
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9142 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
From http://svn.digium.com/svn/octasic_api/oct612x/tags/PR49-03/software@44
This is only currently maintained as part of DAHDI linux so it makes sense to
have it directly in DAHDI linux.
This obliterates any chance of having 0 checkpatch.pl errors between the
2.3.0 and 2.4.0 releases. Oh well...
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9138 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|