Age | Commit message (Collapse) | Author |
|
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
|
|
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>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9584 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9560 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This is a very slight performance improvement. Eliminating the need to
save the IRQ flags is probably more of a boost than grabbing and
releasing the reglock.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9558 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Allow name of EC factory to vary based on channel
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
|
|
Remove name field from echocan ops
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
|
|
The loopup/loopdown T1 maintenance feature in the single through quad-span
drivers now function properly, according to AT&T TR54016, by sending a
full rate pattern down the line. T1.403 ESF/Data Link patterns are not
supported currently.
Also grouped all the maint reset register clears under a single irq lock
to crank the performance up past 11.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9516 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
DAHDI_MAINT_LOOPSTOP is being removed due to the redundancy with
DAHDI_MAINT_NONE. Also removing some timing logic, as amount of time a
loopup or loopdown signal is held on the line, is now defined in
userspace with dahdi_maint.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9515 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The dahdi_span->maintq wait queue was very old and not being used so it
has been removed.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-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@9514 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Renamed the NMF workaround message to the more informational
crc4-multiframe (mis)alignment message.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9461 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Push all tests for the DAHDI_FLAGBIT_NETDEV flag behind a
'dahdi_have_netdev' function so if CONFIG_DAHDI_NET is not defined the
compiler can just remove all the flag tests. Also, makes sure that the
bit is checked / set atomically.
(closes issue #9379)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9444 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The check for DEFINE_SPINLOCK was spread throughout the source tree. If
not defined we can just define it in inlucde/dahdi/kernel.h. Now
include/dahdi/kernel.h is the only place that references
SPIN_LOCK_UNLOCKED (which breaks lockdep checking if DEFINE_SPINLOCK is
otherwise defined in the kernel).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Review: https://reviewboard.asterisk.org/r/940/
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9411 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>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9400 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Normally you can see RBS bit states in dahdi_tool, but you might also
want them logged to dmesg for troubleshooting.
(issue #18025)
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@9399 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9320 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
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9312 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
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9105 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@9102 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Due to the very small number of affected customers we have
removed the module parameter "extendedreset" in favor of a
compile time option "CONFIG_EXTENDED_RESET". dahdi-673
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9098 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
works
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9056 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
dahdi_maint
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9051 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9049 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Make setup_chunks static, eliminate a dynamic array in the interrupt handler,
don't cast away a memory region specifier, and don't initialize statics to 0.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9042 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Added the abililty to loop the line back towards the network
for E1 modes. This supports both network loop and network
payload loop.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9019 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9016 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Added support for error counter injection for E1 mode
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9013 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Upon review the event introduced in r8998 seemed to be
redundant, as the same information was already available.
Performance issues were also a concern. This reverts r8998.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9010 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
QuadFalc has the ability to test if the transformer is
performing correctly. If the components between the framer
and the physical span interface are shorted out or opened
for any reason we can now detect it. Possible causes for
tripping this error could be a broken transformer from
an electrical spike or a board manufacturing error.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8999 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When a loss of syncronization signal occurs on one of
the spans, it affects all spans on that card. Since we
do not have a span or card level event system, we have
to queue up a global event on all channels for that card
The new event is DAHDI_EVENT_SYNC
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8998 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
qfalc framer.
Added some more verbose red alarm states in the upper byte
of the alarm member of the dahdi_span structure
Removed some unnecessary instrumentation regarding the enabling
of the errored second and 1 second counters for performance
collecting. Also added a couple comments.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8997 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
One more thing that can be moved out of the per-span structure.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8986 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Part of preparation for adding additional callbacks to allow board
drivers to advertise and support gathering pre-echocan data from hardware
echocans.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8985 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
The vast majority of board drivers already keep the dahdi_span structure
in a driver specific structure. The others were easily converted. This
way board drivers can use the container_of macro to find what was
previously pointed to by the "pvt" member of the span. One less thing
to think about in the span structure.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8984 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
required latency for the board in question.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8968 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8935 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8849 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8841 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
suggestion)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8805 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
RBS modes to be broken when using AMI coding. DAHDI-647.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8801 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
latency - the default number of ms of buffering to start off with
ms_per_irq - how often the card interrupts
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8768 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
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8087 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
* Added logic for both the single and dual/quad span cards for supporting
local loopback (virtual loopback plug), network loopback, network payload
loopback, loopup, and loopback transmitting.
* Added logic for the dual/quad span driver to support exporting the
performance and error counters including :
- errored seconds
- framing errors
- coding violations
- bipolar violations
- crc4 errors
- ebit errors
- fas errors
* Moved the error and performance counters into a substructure for all drivers
taking advantage of dahdi_span bpvcount.
* Modified the DAHDI_SPANSTAT ioctl interface, so I moved the old interface
to DAHDI_SPANSTAT_V1. The new interface comes with a nice, new shiny packed
struct dahdi_spaninfo.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8061 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8008 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|