The dahdi_echocan_* modules had an unused debug_printk() macro. Remove
them because:
* They were unused
* There were multiple definitions
* They were unsafe. Someone doing an
if(foo)
debug_printk(...);
else
do_something();
may be surprised ;-)
* They used 'debug' as a debug level, while the rest of DAHDI debug
macros treat it as a bit-field.
Leave only a single definition in wcte12xp/base.c which is safe.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10459 a0bf4364-ded3-4de4-8d8a-66a801d63aff
USB_RECOV.hex, rev. 9760. It may be used to recover from certain
issues of the USB controller of the Astribank (when an Astribank
is not detected as such) by Support staff.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10455 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In case of error class_create check IS_ERR()/PTR_ERR() and not for NULL.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10453 a0bf4364-ded3-4de4-8d8a-66a801d63aff
show Master change to/from core timer if DEBUG_MAIN (GENERAL) flag is on.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10451 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* A parent-less device should not crash dahdi:
- Access span->parent->dev instead of span->parent-dev.parent
in soem cases.
- Access span->parent->dev via new inline span_device()
- Use span_device() in all dahdi_dev_{dbg,info}()
* Allow low-level drivers to set their device name.
- Drivers that don't use this feature get the default name
based on the parent device name
- Parent-less devices which don't set their name, fails
to register with -EINVAL
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10449 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A slightly newer firmware (Xorcom rev. 7107) for older (non Astribank
II) Astribank modules. Was accidentally left uncommited. Includes minor
bug fixes.
No change for any relatively recent (Astribank II) Astribank.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10443 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Build the OSLEC echo canceller (drivers/staging/echo and
dahdi_echocan_oslec) if the code of oslec is present in the tree.
Also closing another issue regarding documentation of building OSLEC,
as it is now even clearer than before.
Patch has been used in the Debian package for quite some time.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(closes issue DAHLIN-110)
Reported by: biohumanoid (Pavel Selivanov)
Patches:
oslec_auto.diff uploaded by tzafrir (license 5035)
(closes issue DAHLIN-261)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10440 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Wrap in do {} while(0)
* Move closer to its use (it's #undef'ed anyway after this section)
* Also re-organize line-breaking in the same code section
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10434 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Manually place EXPORT_SYMBOL() after symbols (or at end of functions).
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10431 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Synchronize some changes from out internal tree:
* Fix a few of the places where indent did a lousy job.
* sparse did not like using the const MAX_ARGS as an index. Make it a define.
* Incorrect header included in card_fxs.c (doh!).
* One more funciton to statify.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10429 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The VPMOCT128 module was using the VPMOCT256 timeslots assigments which would
mean that channels that should be marked alaw were being set in ulaw. This
only affected E1 spans since by default all spans are configured for ulaw by
default.
This fixes a regression introduced in r10290 [1] "wct4xxp: Add support for
TE820 and VPMOCT256", first released in 2.6.0, that only affects E1 spans on a
quad and dual-span card when used with the hardware echocanceler.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10290
Internal-Issue-ID: DAHDI-945, DAHLIN-275
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@10414 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The DAHDI_ONHOOKTRANSFER ioctl was incorrectly setting the ohttimer to 0. The
result was that an FXS port was leaving the on-hook transfer state before
finishing the transmission.
This was discovered while looking at why ./fxstest dtmfcid was not able to
pass the DTMF callerid digits to an attached FXO port properly.
Fixes a regression introduced in r10167 "wctdm24xxp: Use interval for checking
FXS on hook transfer timer." [1], first released in 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10167
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10413 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* If dahdi_register_device() failed, not all resources were freed.
When dahdi_unregister_device() was called later (during driver
removal) a panic was caused.
* Add proper error handling for possible failures in
xbus_register_dahdi_device():
- new xbus_free_ddev() safely free an xbus->ddev
- This is called from all failures points.
- It is also called from xbus_unregister_dahdi_device()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10410 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* A bug was introduced during migration to dahdi_device code:
http://svnview.digium.com/svn/dahdi?view=rev&rev=10273
* Marking XPDs as non-functional (card_present=0, XPD_STATE_NOHW)
was moved from xbus_request_removal() into xpd_dahdi_preunregister()
* As a result, unregistering an Astribank, made it non-functional
so trying to re-register it later caused errors (e.g: "Cannot open"
error message from xpp_open())
* This fix move XPD deactivation into the proper location (during
xbus_deactivate()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10409 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the hook state on an FXS port changes before the channel is
configured with dahdi_cfg it is possible to erroneously force the line
feed register open without setting a timer to clear it.
The result would be a "dead" channel that cannot be cleared unless the
driver is reloaded and warning in the kernel log that "0 is an invalid
signaling state for an FXS module".
This change makes the OFF_HOOK to ON_HOOK change behave just as the
ON_HOOK to OFF_HOOK change has.
Internal-Issue-ID: DAHLIN-272
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@10396 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It is not necessary to wait a full second for the donebit.
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@10395 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* We need to split the BRI D-Channel (HDLC) frames to smaller packets,
limitation of the FPGA.
* This changes batches BRI D-channel packets of the same HDLC frame to a
single XPP frame.
* Avoids an accidental fragmantion in case we were delayed for a few ms-s.
* Also improves efficiency.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10390 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* The zero lenth case (Magic request) was split into
send_magic_request() function. It was not possible
to move it into card_bri.c, because it is called
directly from the general interface we provide for
register read/write via sysfs/proc.
* The normal case (send_multibyte_request) was moved from
card_global.c into card_bri.c
* This sets the stage to enable bundling of multibyte
packets into frames (like we do for PCM).
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10389 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Now that legacy BRISTUFF code is gone, some wrapper
functions became trivial. Removed these wrappers
and inlined their contents.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10388 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is also a work around the bug fixed in the previous commit.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10384 a0bf4364-ded3-4de4-8d8a-66a801d63aff
module_put() that was added while developing the sysfs code. The real
module_get()/module_put() pair were already removed at the time of
developing code for this branch. It was only triggered when using a
system with more than 32 (MAX_BUSES) Astribanks.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10383 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I've seen some platforms that do not properly route the interrupt from the
card to the host CPU. In these cases the card potentially could appear to be
greened up even though no data is flowing over the spans.
This change allows dahdi_cfg to return an error when this occurs, and also
ensures that all the spans are in RED alarm.
For example, dahdi_cfg output when the card is not generating interrupts:
# dahdi_cfg
DAHDI startup failed: Input/output error
And the kernel log will contain a string like:
wct4xxp 0000:02:08.0: Interrupts not detected.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10380 a0bf4364-ded3-4de4-8d8a-66a801d63aff
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
voicebus_release is already called as part of the wctdm_back_out_gracefully()
call. If an Hx8 card fails to initialize, this will eliminate warnings from
the kernel such as:
WARNING: at kernel/irq/manage.c:904 __free_irq+0x94/0x173()
Trying to free already-free IRQ 18
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10377 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Use similar caculation as in the PRI module:
* Save timing_priority from spanconfig and
elect syncer when spanconfig is called.
* Create custom timing_priority() function that returns
the value or error if span is disconnected.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: : Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10373 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* We must not block PCM during from 'search_fsk_pattern' channels.
* We must vmwi_search() not only on FXS_LINE_POL_ACTIVE, but also during
'neon_blinking' -- so we notice the message to turn it off.
* Also added 'search_fsk_pattern' and neon_blinking to /proc/.../fxs_info
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: : Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10372 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Renamed most of the "vpm450m" references to just "vpm".
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10365 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Commit de47725, first released in 3.2-rc1 removed module.h from some
kernel headers. Include it explicitly now.
Resolves compilation errors like:
error: implicit declaration of function 'try_module_get'
error: 'THIS_MODULE' undeclared (first use in this function)
error: implicit declaration of function 'module_put'
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10361 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The ndo_set_multicast_list callback was removed in b81693d9, which was
first released in Linux Kernel 3.2-rc1
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10360 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Restores the pri_protocol attribute of the XPD node in SysFS to be
writable. Fixes a minor regression from the pinned-spans fix, similar to
r10334.
* This attribute was made R/O in digium r10280 as part of the
pinned-spans changes:
- The E1/T1 settings were changed via new set_spantype() method
which was called from dahdi when the 'spantype' dahdi attribute
was written to.
- This fails our init_card_4_* trying to write E1/T1 into our private
attribute.
* Restored our old code (with minor modifications) so we
can set E1/T1 the old way (writing to our 'pri_protocol' attribute)
as well as the new way (when it will be used eventually).
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10347 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Force some reserved bits to really be 1 in E1 mode (otherwise
terrorists will win).
(Closes issue DAHLIN-264)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10346 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A length of 1000 commands is not enough is some cases with CAS.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10341 a0bf4364-ded3-4de4-8d8a-66a801d63aff
An extra fix that was accidentally not included in r10013. Minor bug fixes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10337 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This restores a somewhat limited functionality of the "span"
write interface in the SysFS node of the span, broken by the
pinned-spans code.
* PROBLEM: dahdi-linux pinned-spans should work with existing dahdi-tools
specifically the dahdi_registration tool.
* As a result, we should still be able to control dahdi registration
order. However, registration is now in complete devices and not spans
* Restored dahdi_autoreg=[0/1] xpp module parameter:
- It now refers to complete astribanks and not individual spans
* The xpp module sysfs "span" attribute:
- Implemented write method (for dahdi_registration tool)
- The first write of [1/0] to this attribute, registers/unregisters
the complete astribank
- Further writes are ignored (with DBG messages)
* Also, implemented new xbus_is_registered() function
* Once the new dahdi-tools are merged, we should turn deprecation
messages from DBG() to NOTICE()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10334 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Some of the VPM loading / probing threads use global system workqueues. They
might now be running when we abort early so we should wait for them to
complete their runs before freeing memory that may be in use.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10332 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
USB_FW rev 9964: includes a few stability bugfixes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10323 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Removed a couple prints of instrumentation that was cluttering up the log output.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10310 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
The NOTOPEN span alarm flag is set at span unassignment time.
* It needs to be cleared when the span is reassigned.
* That is: only if the span is actually connected.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10302 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* An xbus transport now have a "model_string" member
* The xpp_usb driver fills this with "usb:<idVendor>/<idProduct>/<bcdDevice>"
* It is passed via environment to the "init_card_<type>_<protocol>" scripts
* The FXS script uses this to condition two registers according to
the power supply model.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10300 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since "wctdm24xxp: Probe for and configure modules in parallel." the
check for the VPMADT032 module was moved closer to after when the
interface was initialized. The 200ms timeout did not provide enough
time for the system to settle out after initial start. The result
was that sometimes after a cold boot the driver would fail to detect
any VPMADT032 modules.
This fixes a race condition that is not in any released branches.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10296 a0bf4364-ded3-4de4-8d8a-66a801d63aff
- Cleaned up the OCT6114 interface .
- Relaxed the timeout waiting for OCT6114 bus cycle completion to 100 mS
and added a 2 mS delay time from OCT6114 reset to initialization.
This change only addresses issues that were created in the lab and not in the
field.
Signed-off-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10295 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This will allow the serial number to be exposed in sysfs and also
allow span assignment rules to use the serial number.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10292 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This commit adds field upgradeable support for the TE820 firmware.
Firmware can now be silently upgraded as part of updating drivers
like most of the existing DAHDI firmware. Previous versions of dual
and quad span cards did not support upgrading firmware in the field.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixed up some checkpatch issues:
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10291 a0bf4364-ded3-4de4-8d8a-66a801d63aff
TE820 is an 8-span PCI-express digital interface card. VPMOCT256 is a hardware
echo canceler that is able to provide echo cancelation on all 8-spans.
From: Matthew Fredrickson <creslin@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10290 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* So we can:
- Generate 'pinned-spans.conf' from existing state
- Run dahdi_cfg from udev (on specific span + its channels)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10286 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
* With pinned-spans all spans are registered to dahdi with the
device (and assigned later)
* So this parameter cannot function anymore
* Also remove the (now) empty xpd_post_init() function.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10284 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Otherwise, a failed unit initialization (e.g: when init_card_?_?? fails)
causes a panic
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10282 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Reparent astribanks below their USB transport
* This way their location can be derived from their hardware
hierarchy.
* The tradeoff is that once USB hardware is disconnected, there
is no sysfs visibility of the astribank object even if it
cannot be release yet due to open channels by asterisk
* Thus, we'll need to migrate to "surprise removal" of dahdi
devices...
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10281 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Implement pri_set_spantype() method
* Refactor code from PRI_card_dahdi_preregistration() into
a new apply_pri_protocol().
- It is now called from both PRI_card_dahdi_preregistration()
and set_pri_proto()
- It now also sets span name + description
* Remove old pri_protocol_store() method (pri_protocol is now RO)
* Added pri_protocol_bystr() method (maybe promote it to DAHDI?)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10280 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allowing the linemode to be configured with sysfs before the spans are
assigned opens the eventualy capability for line mode to be configured
with the other physical layer settings per card. Currently linemode is
set with either physical jumpers or with a module parameter to the
wct4xxp driver that is global for all cards.
Default behavior is not changed with this commit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10279 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allowing the linemode to be configured with sysfs before the spans are
assigned opens the eventualy capability for line mode to be configured
with the other physical layer settings per card. Currently linemode is
set with either physical jumpers or with a module parameter to the
wcte12xp driver that is global for all cards.
Default behavior is not changed with this commit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10278 a0bf4364-ded3-4de4-8d8a-66a801d63aff
For some boards, the linemode (E1/T1/J1) is software selectable but
needs to be configured before the spans were historically registered
since the line mode determines the channel count available on the span.
This change exports a "spantype" attribute from the dahdi_device that
can be used to set E1/T1/J1 before the spans are assigned. When
userspace writes to this attribute (in a <span offset>:<span type
string> format), and if the board driver has implemented a set_spantype
function in it's dahdi_span_ops, then the board driver can optionally
change it's mode before registration.
Also part of this change is breaking out the raw data structure
initialization of the spans / channels via the dahdi_init_device_spans
function since the board drivers may need to reallocate channels / spans
as part of this callback. For example, changing from T1 to E1 mode will
require allocating 7 new channels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10277 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
't1e1override' isn't immediately apparent what it is supposed to do by the
name. Instead 'default_linemode' module parameter can be set to "auto", "t1",
or "e1" to make it clear.
This change was introduced earlier in the wcte12xp driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10269 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I only generally test on RHEL 4 when testing against kernels older
than 2.6.18. Apparently OpenSUSE 10.1 runs with 2.6.16 and doesn't
have WARN_ON_ONCE backported. I took the patch Richard Miller
originally attached to the issue and moved it to
include/dahdi/kernel.h so it would be available for all the board
drivers in the future.
Internal-Issue-ID: DAHLIN-260
Reported-by: Richard Miller
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10252 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes an issue where "EC: LASVEGAS2" was displayed in /proc/dahdi/x
for a B410P span even though vpmsupport was disabled with the module
parameter.
Internal-Issue-ID: DAHLIN-247
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10251 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allows the globalconfig member to be removed from the struct t4 and not
carried around for the life of the card. Also holds the reglock a little
longer for all the framer writes but I realize the startup of the
wct4xxp based cards does not need to be optimized.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10250 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Reduces the amount of code to read in the two functions and fixes
checkpatch.pl warnings.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10249 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There are read/modify/write operations on the framer that were not
protected by any locks. While I didn't notice any code paths that would
result in simultaneous accesses to these registers, this change will
hopefully save someone else some time in the future verifying that the
accesses are safe. A side effect is that the reglock is acquired only
once for each read/modify/write cycle as opposed to twice previously.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10248 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since 'linemode' more accurately describes what spantype is specifying.
We can also use an enumeration for the linemode to make it explicit that
linemode is only set to one of three possible values.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10246 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Use some convenience pointers to make the function easier to read as opposed
to indexing into the arrays.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10245 a0bf4364-ded3-4de4-8d8a-66a801d63aff
All those checks for wc->t1e1 span appear to basically be there to
determine if there are *any* E1 spans exported by the card. We can make
that explicit by wrapping those tests with a has_e1_span() inline
function to help with readability.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10244 a0bf4364-ded3-4de4-8d8a-66a801d63aff
't1e1override' isn't immediately apparent what it is supposed to do by the
name. Instead 'default_linemode' module parameter can be set to "auto", "t1",
or "e1" to make it clear.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10243 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since removal of the VPM400 support the 'vpm' member of struct t4 is
now redundant with the 'vpm450m' member.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10242 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The VPM400 module is no longer supported by the wct4xxp driver. The
VPMOCT064 and VPMOCT128 are.
Signed-off-by: Russ Meyerreicks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10241 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Saves about a 1us on average from the interrupt handler on one test
system.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10239 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Eliminates the need to store a copy of the flags and variety from the
global devtype.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10238 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'memaddr' and 'memlen' is already cached as part of the underlying pci
device so the wct4xxp driver does not need to cache it again. 'canary',
'passno', 'master', and 'oct_rw_count' are unused.
In t4_span 'irqmisses' was incremented, but never used anywhere, and there is
already the irqmisses on the span itself.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10237 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I was unable to measure a performance change with prefetching.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10236 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We are already in hardirq context and can therefore save the cli/sti
call.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10235 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Speeds up these calls primarily by eliminating unnecessary flushes
of writes to the PCI bus.
Before:
7.095 us | __t4_framer_in();
5.835 us | __t4_framer_out();
7.122 us | __t4_framer_in();
7.071 us | __t4_framer_in();
7.059 us | __t4_framer_in();
5.859 us | __t4_framer_out();
7.076 us | __t4_framer_in();
5.852 us | __t4_framer_out();
7.124 us | __t4_framer_in();
7.080 us | __t4_framer_in();
After:
1.694 us | __t4_framer_out();
1.686 us | __t4_framer_out();
1.695 us | __t4_framer_out();
3.182 us | __t4_framer_in();
3.283 us | __t4_framer_in();
2.889 us | __t4_framer_in();
2.942 us | __t4_framer_in();
2.951 us | __t4_framer_in();
2.906 us | __t4_framer_in();
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10234 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The 'pedanticpci' module parameter, which is always on by default,
inserts extra reads from the card in order to ensure that all writes are
properly flushed through any PCI bridges which may post the writes. The
side effect is that this takes more CPU time for registers reads and
writes, especially to the framer registers.
It is never recommended to run with pedanticpci set to 0, so I'm
removing it as a module parameter so that the default case does not take
a performance hit checking for whether the parameter is set or not.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10233 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Also has the nice side effect of eliminating a comparison from the
interrupt handler.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10232 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The overhead of reading the framer registers is significant and can
result in latency bumps / data drops on heavily loaded systems.
Instead of checking all spans every millisecond when they are in
alarm we will instead only check every 100 ms.
On one test system, dropped the % CPU time spent in hard interrupt
context from 10% per TDM4XX when all four spans are in alarm to
closer to 2%.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10231 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is the "normal" condition and can be lumped with the other
informational messages. Otherwise, just this one message might go to the
console depending on the system configuration which can be confusing.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10230 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This value is not used and is now gone.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10229 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10160 "wctdm24xxp: Probe for and configure modules in parallel."
did not properly setup the VPMADT032 for all ports on hybrid cards.
The most immediate sympton being that spans 3 and up on a hybrid
card would not come up in Asterisk even though they were out of
alarm. This was because the echo canceler was blocking messages on
the dchannels.
This does not affect any previously released versions of DAHDI-Linux
or users of the VPMOCT032.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10228 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Uses the linecompat member to determine what type of span it is. This will
allow removing T1/E1 flags from other places where the span type is stored.
This function also changes the return value from bool to int for the
inlines defined in include/dahdi/kernel.h. This is because not all
kernel versions include stdbool.h in the headers and it will conflict
with boolean values that are exported via module parameters on some
older kernels if dahdi included it globally.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10227 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Commit r9750 "wct4xxp: Reduce the memory footprint of the hardware
echocanceler.", as part of reducing the non-pageable memory required to
support the VPMOCT064 and VPMOCT128, disabled caching of some hardware
echocan registers. This resulted in more physical reads to the echo
canceler. These new read transactions exposed an existing issue where
sometimes reads could be turned into writes which put a channel into an
unintended state preventing Asterisk from detecting any DTMF.
This issue is resolved by ensuring that the write signal to the Octasic
part is explicitly cleared between when the address is presented on the
bus and when the read and chip select signals are asserted. The cost is
an increase in the average time to enable / disable echo cancellation by
about 5 us on one Intel Xeon X3220 test machine (~250ns increase per
read from the Octasic part and 20 reads to enable / disable a channel).
This commit resolves a behavioral regression first introduced in 2.5.0
and 2.4.1 which could take many calls before revealing itself. This
change only affects cards with a VPMOCT128 or VPMOCT064 installed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Doug Bailey <dbailey@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10220 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The driver has, until now, dropped G723 SID frames even though the
firmware on the TC400/TCE400 can handle them. Now let them on
through.
Reported-and-Tested-by: Angel Carhuas <acarhuas@colinanet.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10218 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The intent here is to flag to users that the maintenance counters are
not collected for spans exported by the wcte12xp driver.
dahdi_maint before this change:
# dahdi_maint -s 1
Span 1:
>Framing Errors : 0:
>CRC Errors : 0:
>Code Violations : 0:
>E-bit Count : 0:
>General Errored Seconds : 0:
And after:
# dahdi_maint -s 1
Span 1:
>Framing Errors : -1:
>CRC Errors : -1:
>Code Violations : -1:
>E-bit Count : -1:
>General Errored Seconds : -1:
This can be combined with a change to dahdi_maint to recognize that the
errors are -1 and print an even more explicit warning.
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@10212 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Currently, the devicetype string was set both when the device was first
allocated and updated when an echocanceler was detected. For simplicity,
combine both these steps into a single function.
This change also replaces an improper use of strncat with strlcat.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10210 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* 'D' DTMF digits were accidentally discarded with the notice message:
"Bad DTMF value 0. Ignored".
* No need for an odd 1-based translation table anymore - it's 0-based.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10209 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
These members are not used anywhere and are now gone.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10204 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A "(VPMADT032)" string is appended to the devicetype (as shown by
dahdi_scan) for the span if one is installed. Now append '(VPMOCT032)'
if one is installed as well.
Also, for the wcte12xp driver append the VPM name to the device type after
initially probing as opposed to only after the span is configured.
(Related to issue DAHDI-890)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10203 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Bug sympthoms: wrong FSK VMWI sent few seconds after
offhook. That was caused because the driver kept
polling the (physically unconnected) digital inputs.
[note: a workaround for drivers without this patch
is to zero the 'xpd_fxs.poll_digital_inputs' parameter.]
* Also, the digital_inputs/digital_output masks were
calculate using a different condition.
* Now we determine number of channels, digital inputs and
digital outputs in a single place and use this info
later to calculate the correct masks.
* We poll only if there are digital_inputs
* We added a sanity check in process_digital_inputs, so
we get a notice if it's called on an xpd without digital
inputs (e.g: hypothetic firmware bug).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10202 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
New firmwares to handle the new 2FXS/6FXO module.
FPGA_1161.hex, PIC_TYPE_1.hex, PIC_TYPE_2.hex of internal rev. 9732
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10179 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Firmware version 1.11.0 resolves an issue where the driver fails to
detect certain VPMOCT032 modules after a cold boot.
Signed-off-by: Doug Bailey <dbailey@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10172 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The driver / FXO modules now always operate in a fwringdetect mode and the
module parameter was never checked anywhere. It is now gone.
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@10171 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Eliminate the assumption that the check function is going to be called
for every frame. Also use a state machine to make polarity debouncing
similar to the other debouncing code.
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@10170 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allows the driver the option of not calling the misc function for every
frame. This is part of preparation for moving misc processing out of
the interrupt handler. Also use a state machine for the various battery
states to unify the technique for debouncing the various signals in the
driver.
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@10169 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Do not assume the ring detection function is called for every frame.
Also change the debounce logic to a state machine to clarify what state
a port is in and unify the technique for debouncing the various signals.
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@10168 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of moving more of the module specific processing out of the
interrupt handler and allowing the interrupt rate to be slowed down.
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@10167 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of preparations for being able to optionally slow the interrupt
rate down and opening the door for moving more module processing out of
the interrupt handler.
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@10166 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Saved me time when reading the code so I don't have to lookup which position
in the index is what register for each of the modules.
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@10165 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The variable does not necessarily have anything to do with the frequency
of interrupts but is instead a count of sframes received. For example,
it is possible to slow the interrupt rate down on the voicebus cards to
one every 2 frames.
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@10164 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We can spend less time in interrupt context by not saving and restoring the
local interrupt state. This is a particularly noticeable improvement on debug
kernels with lockdep.
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@10163 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Closes a small window of opportunity where one CPU might free a VPM
instance that the interrupt handler may currently be using.
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@10162 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Wait until we have de-bounced the presence of battery before moving on the
check for changes in polarity. This removes the sometimes random
polarity messages generated on an FXO port when the far side drops
battery from a supervisor disconnect.
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@10161 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Use the newly create bg_create and bg_join to actually probe / configure
groups of 4 modules in parallel. This currently has to be done in groups
of four due to the way 4-port modules are identified relative to single
port modules.
This provides a dramatic improvement in driver load time. When loading a
single TDM2400 with 24 FXS ports before this change:
# time modprobe wctdm24xxp vpmsupport=0
real 0m46.674s
user 0m0.000s
sys 0m0.520s
And after this change:
# time modprobe wctdm24xxp vpmsupport=0
real 0m7.900s
user 0m0.000s
sys 0m0.070s
Note that the boards themselves are still configured serially. Board
configuration can be parallelized once the assignment of board position
is moved out of the function that is run in parallel. Otherwise it could
be possible for board numbers to switch on repeated loads.
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@10160 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Create a generic facility to spawn tasks to run in parallel. There are
interfaces already in the kernel for doing this, but they are not
supported on the full range of kernels that DAHDI must support.
This will be used to identify and configure FXS/FXO/B400M/VPM modules in
parallel.
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@10159 a0bf4364-ded3-4de4-8d8a-66a801d63aff
