* Adds a new parameter, 'lower_ringing_noise', to module xpd_fxs.
* Makes the "power-down" behaviour that was added
in upstream svn r10478, switchable in runtime.
* By default (false), makes the vbat_h behave like it did
before the power-down change.
- I.e: vbat_h is held throughout the ringing period (during
both ring-up/ring-down)
- So this patch revert part of r10478
* When switched to true, activate the "power-down" behaviour.
- I.e: vbat_h follows the ring-up/ring-down.
- This behaviour lowers the noise caused by group ringing of
FXS channels in the same unit, but causes problems with CallerID.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10574
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10578 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* In do_chan_power() make vbat_h changes atomic.
* As a result we can ignore duplicate requests.
This will allow cleaner logic in the next commit.
* Added proper debug messages.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10573
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10577 a0bf4364-ded3-4de4-8d8a-66a801d63aff
USB firmware (USB_FW.201.hex 10402) and FPGA firmware
(FPGA_1161.201.hex 10480) with support of the new E-Main 4 Astribank
mainboard.
(This was accidentally labeled as 'E-Main 3' in some previous commit
messages)
Also includes Makefile fixes from r10536.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10535
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10540 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes an issues with the 6FXS/2FXO module: if an extra FXS or FXO module
is added to a system with such a module, an excessive number of port
licenses was accidentally required (as if the 6FXS/2FXO module required
8FXS/8FXO licenses).
Internal-Issue-ID: #1371
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10534
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10539 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Upstream commit bd77c047 "module: struct module_ref should contains long
fields" changed the return of module_refcount from int to unsigned long. This
change eliminates a warning from the string format specifier.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10485
Conflicts:
drivers/dahdi/xpp/xproto.c
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10529 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10396
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10527 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Now every linefeed control command which is not RING'ing
powers-down the SLIC. This reduce audible noise when
several channels are ringing.
* Simplify code by removing redundant calls to do_chan_power()
before linefeed_control()
* Manage vbat_h state so we skip do_chan_power() calls when
there isn't a state change
* Export vbat_h state to /proc/.../fxs_info
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10478
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10488 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)
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10440
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10441 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/branches/2.5@10394 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/branches/2.5@10393 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/branches/2.5@10392 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/branches/2.5@10385 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10377
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10378 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/branches/2.5@10376 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/branches/2.5@10375 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10361
Conflicts:
include/dahdi/kernel.h
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10363 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/branches/2.5@10353 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/branches/2.5@10351 a0bf4364-ded3-4de4-8d8a-66a801d63aff
An extra fix that was accidentally not included in r10324. Minor bug fixes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10338 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10304
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10305 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10252
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10254 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10220
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10221 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.
Additionally, on the 2.5 branch, this change actually makes r10206
"wctdm24xxp, wcte12xp: Advertise VPMOCT032 presence in
dahdi_span.devicetype", work the way it was originally intended. That
change was only functioning properly previously on trunk.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10210
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10211 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/branches/2.5@10208 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10205
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10207 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10203
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10206 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10200
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10201 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/branches/2.5@10180 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10006 "wctdm24xxp: Add 'fastpick' module parameter." copied the
fast-off hook module parameter from the wctdm.c driver, but the setting
in that driver does not match the data sheet. The previous commit did
not actually change any of the significant bits in that register. Also,
that commit changed the timer, but did not disable the callibration
delay which is necessary for Type-II callerid.
The fastpickup option in the wctdm24xxp driver should now match the
fastpickup option in the wctdm driver.
DAHDI-224.
Reported-By: Kinnith Wallace <kwallace@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10148
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10150 a0bf4364-ded3-4de4-8d8a-66a801d63aff
