Previous commit (r10651) included an incorrect version. Including full message
from that commit for the description.
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10652
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10654 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10649
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10651 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It appears that some kernel configurations do not include timer.h in any of
the include files that are included by dahdi_dummy. The timer_structs are
defined in timer.h and not time.h, so this change is correct even though I
never could find a configuation myself that actually failed to compile.
This has negligible impact since dahdi_dummy is not compiled by default.
Internal-Issue-ID: DAHLIN-185
Reported-by: Steve Murphy
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10640
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10644 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Minor change to follow generally recommended practice. Prevents new packets
from being queued up for devices when they are about to be cleaned up. Also
clean up any skbs that may still be on the queue after unloading.
Also closes anoter potential kernel oops on module unload. It was possible to
delete the private structure while the master span process was running. The
result was an attempt to page memory from interrupt context.
Make sure that the pvt function is set and cleared under the zlock. Also do
not assume that the pvt pointer is valid in ztdeth_transmit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10626
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10631 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The board drivers are the ones calling the unregister function, and
therefore we do not need to worry about them unloading while calling the
destroy callback.
When destroying spans with the ioctl, replace __module_get() with
try_module_get. This avoids hitting a BUG in module_get on kernel versions <
2.6.29.
ALSO move the call to try_module_get out of the dahdi_dynamic_release function
and into destroy. This way if the destroy callback isn't called because the
dynamic driver is unloading the dynamic device can be left on the list to be
cleaned up by the dahdi_dynamic_unregister_driver function().
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10624
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10629 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Instead of registering a function pointer, register a dahdi_dynamic_ops
structure that contains the owner as well as the ioctl callback. This way
dahdi.ko can bump up the reference count on dahdi_dynamic.ko before calling
the ioctl callback.
Also, use the registration mutex to guard against the module being unloaded
between the time the structure pointer was checked, and the module reference
is taken.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10623
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10628 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Enables the driver to update firmware on systems that do not have the firmware
loader configured / enabled (Linux config option CONFIG_FW_LOADER). Compiling
the firmware into the driver increase the memory footprint by around ~440K.
Internal-Issue-ID: DAHDI-963
Reported-and-Tested-by: Guenther Kelleter
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10618
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10620 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The driver makes the assumption that interrupts are disabled but this cannot
be guaranteed. We'll explicity disable interrupts on the local processor while
the interrupt handler is running.
This eliminates the "IRQF_DISABLED is not guaranteed on shared IRQs" warning
when loading the driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10589
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10593 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Resolves the follwing build error:
drivers/dahdi/dahdi_dynamic_eth.c: In function ‘ztdeth_exit’:
drivers/dahdi/dahdi_dynamic_eth.c:448: error: implicit declaration of function ‘cancel_work_sync’
RHEL kernel versions 2.6.18-238 (5.6) and greater had cancel_work_sync()
backported which is what I did my original smoke test on.
Reported-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10588
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10592 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It was possible after a dynamic ethernet span was created for a packet to come
in before the dahdi_span was fully initialized. The result would be a NULL
pointer dereference. Now just discard any packets that might come in during
this time window.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10587
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10591 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* 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.6@10576 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.6@10575 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This in conjunction with r10449 "A parent-less device should not crash dahdi",
this allows dahdi_dynamic spans to work post the dahdi_devices changes in
2.6.0.
The full address of the device is not used since kernels prior to 2.6.31 limit
the length of a devicename to 20 characters. The full address of the device
can be pulled out of the "hardware_id" and "type" fields of the span.
This patch is just to get things working again. dahdi_dynamic devices *may*
still have issues if the auto_assign_spans module parameter is 0.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10563
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10571 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is needed because dev_name() is mapped to kobject_name() in a backport,
but the kobject name isn't set until after device_add(). The result would be
parentless devices would fail since dahdi would not think a name was set for
these devices.
For these systems, we'll set both the bus_id string and the underlying
kobject_name.
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=10561
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10569 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10449
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10568 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Certain BIOSes appear to enable ASPM even though it is not fully supported by
the platform. Also, since the PCIe links for TDM cards are always in use it
does not make sense to allow them to transition to the disabled state.
Just turn off power management on the PCIe links completely. For more
information see http://lwn.net/Articles/449448/.
Internal-Issue-ID: DAHLIN-283
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10557
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10567 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Certain BIOSes appear to enable ASPM even though it is not fully supported by
the platform. Also, since the PCIe links for TDM cards are always in use it
does not make sense to allow them to transition to the disabled state.
Just turn off power management on the PCIe links completely. For more
information see http://lwn.net/Articles/449448/.
Internal-Issue-ID: DAHLIN-283
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10558
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10566 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a partial revert of r10234 "wct4xxp: __t4_framer_in and
__t4_framer_out speedups."
There were some platform + firmware version combinations that would fail to
properly configure the framer with the aforementioned speedups. The originally
reported sympton was that interrupts would fail to start and while
troubleshooting I also saw cases where one of the spans would stay in alarm
after starting. By adding in additional reads to the version register, the
overall process of writing / reading from the framer control registers is
slowed down which increases reliability.
This change does *not* affect the main path of TDM data which is DMAed
directly into buffers in host memory and are not read / written to / from
framer registers directly.
Reported-and-Tested-by: Vahan Yerkanian <vahan@arminco.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10559
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10565 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.6@10538 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.6@10537 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Even though dahdi_dummy is no longer built by default, the adoption of
dahdi_devices in 2.6 broke the ability to compile. This was not intended as
there are some packagers who still patch the Kbuild file to enable
dahdi_dummy.
Internal-Issue-ID: DAHLIN-274
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10486
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10526 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.6@10525 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.6@10490 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In commit r10168 "wctdm24xxp: Use time interval for debouncing FXO ring
detect" [1], I inadvertently changed the debounce interval of the RINGOFF
event from 128ms to 512ms. The result was a potential failure to detect CID,
depending on line conditions, since Asterisk would bump the rx gains on the
channel in the middle of the CID spill as opposed to before the CID spill.
This fixes a regression first introduced in DAHDI-Linux 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168
Internal-Issue-ID: DAHDI-951
Reported-and-Tested-by: Jack Wilson <ljwilson@digitalav.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10473
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10481 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.6@10442 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10410
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10419 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10409
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10418 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10414
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10416 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>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10413
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10415 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
