Age | Commit message (Collapse) | Author |
|
It's not really useful, and it breaks building 'docs' without a kernel tree.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8538 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
WARN_ON_ONCE is not defined in 2.6.9, and this condition would be catastrophic
anyway if it were to occur.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8494 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8489 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8488 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8487 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8482 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If we try to unload the driver soon after a high latency event, it is possible
to get stuck for several seconds reloading the firmware. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8481 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8480 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8479 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Only program the VPM in spanconfig if it either is not setup, or if it fails a
ping test. Also, if the channel config fails (but ping would otherwise work),
force a reset / reconfiguration if the VPM module. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8478 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Also, fall back to any software echocan configured for this channel for new
calls while we're in the middle of a recovery.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8473 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When the transmit descriptor runs out completely, there (appears to be) a
chance for a random command to be sent that results in the VPMADT032 to no
longer respond, typically resulting in one way audio. This change introduces
a poll of the VPM. If it fails the poll, it will be bypassed temporarily
while the driver resets and reprograms it. Also, the VPM is initially
programmed in the spanconfig callback instead of at driver load. This moves
the potential for underruns until later in the boot process. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8468 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This will make us two behind, which is fine, and eliminates a busy loop in
atomic context.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8467 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8466 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
r8454 and r8460 introduced a change where writes are not retried when other
module/framer commands are retried. This was an error and wasn't what was
actually under test. This commit restores the behavior in wctdm24xxp and
makes sure the vpm writes are retried in the wcte12xp.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8461 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Closes a memory leak when processing the VPM write commands introduced in
r8454.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8460 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When the latency is large and register reads can take 100s of milliseconds, the
alarm polling function could tie up one of the global workqueue threads long
enough to interfere with other system operations. Most noticeably the console.
DAHDI-573
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8455 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Latency conditions could cause the driver to misconfigure the VPM which
would result in one way audio. DAHDI-572.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8454 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Now the errror injection code prevents placing the driver into a loopback
state in a less forceful way.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8443 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The Hx8 series cards do not need any idle buffers and idle_buffers complicate
processing when using the timing_cable. This change adds another mode of
operation for the voicebus layer for the Hx8 cards that operates without the
idle buffers.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8431 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
(closes issue #16493)
Reported by: nic_bellamy
Patches:
wcb4xxp_swyx_sx2_quadbri_pci_ids.patch uploaded by nic bellamy (license 299)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8423 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Resolve two open issues. One of them that accidentally wasn't closed.
(closes issue #15446)
(closes issue #16447)
Reported by: lpistone
Tested by: okrief
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8421 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Wouldn't compile on kernels >= 2.6.20.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8416 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
So just push all the maintenance mode processing off to the workqueue.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8415 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Since t1xxp_maint can be called from interrupt context with the
DAHDI_MAINT_LOOPSTOP cmd, push the processing of that command to a workqueue
since it may sleep in the t1_getreg call. DAHDI-560.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8410 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8405 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If we timeout a command, don't free it right away unless we are the one who
removed it from whatever list it was on. Also, increase the timeout (2 seconds
wasn't enough when the firmware for the VPMOCT was being loaded on a system with
4K stacks) and check the return value from t1_getreg in case there were timeouts.
DAHDI-560.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8400 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8399 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8387 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
* If the receive packet isn't the correct size, we can't just drop it, we have
to resubmit it to the receive queue immediately so it will get cleaned up
properly.
* It isn't safe to leave the buffers on any lists while calling
the function to resubmit it to the descriptor ring, since it may be freed
which potentially results in a corrupted list.
* If the card is held up in a state where it is waiting for receive data, there
is a chance that when the transmit process is started up again it could DMA
data into a buffer that has already been freed. By using our own freelist,
there isn't a chance that the board will DMA data into memory that has been
recycled for another purpose.
* Disable the tasklet when processing hard underruns in order to not corrupt the
descriptor rings.
* Make sure voicebus_stop and voicebus_release aren't running at the same time
as the hard underrun handler. This too can result in corrupted descriptor
lists.
DAHDI-560.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8379 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Oddities in the receive processor state make this completion not so useful
anymore. It is more straightforward to simply poll the state on shutdown.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8378 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Since the locking will always take place in a bottom half now (either a timer or
tasklet), we do not need the special locking macros anymore.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8377 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8376 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8375 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8370 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8360 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Add a number of printk-like macros to print messages for span and
channel. I found them useful in the sysfs branch.
The _dbg ones use the magical variable debug, and hence require the code
to acknowledge that explicitly by defining DAHDI_PRINK_MACROS_USE_debug
explicitly.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8354 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
* Run programs from live tree rather than tools dir (not copied)
* Calculate MODULES dir after reading config file (you'll still need to
override it from the command line for building, but not for reload)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8347 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fixed a minor issue where stateless DAHDI_MAINT ioctl commands, such
as error insertion and clearing, were indicating the span going into
loopback alarm state when it really was not.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8298 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
* Fixed the bug where the card could not be brought out of local
loopback in E1 mode.
* Fixed a bunch of issues where the drivers didn't report unsupported
maintenance functions correctly.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8291 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8279 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Looping modes are now mutually exclusive. If two looping modes are enabled
simultaneously it tends to hose up our framer chip. Now, all looping modes are
cleared in the driver before any are set.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8274 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8255 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8250 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
E1 selection. DAHDI-553
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8245 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8220 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Brings in any backward compatibility definitions.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8204 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
In testing this option didn't appear to function properly. Just mark it debug
only so it's not part of the "official" interface in case there are some users
of it out there that I'm not aware of. DAHDI-267.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8203 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Setting the maximum latency can be useful if you have a system event that
normally causes a latency increase, but you would rather have a break in the
audio or frame slip, then let the latency grow to the current default maximum
which is 25ms. DAHDI-278.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8198 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8189 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|