1) Enabling multiple csm_encaps channel commands in a single packet.
2) Sending commands to separate channels in parallel.
This reduces the time waiting for the responses to the commands and brings in
the channel setup from 50ms to under 10ms.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
interruptible_sleep_on_timeout() has been deprecated for awhile and was finally
removed in Linux 3.15. Since interruptible_sleep_on_timeout() uses jiffies for
the delay, I assumed that each jiffy equated to 10ms given the age of the
driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Some architectures, like arm, do not automatically pull in the definitions for
kzalloc and friends. This allows DAHDI to build on those platforms.
Originally reported to the asterisk-users mailing list here
http://lists.digium.com/pipermail/asterisk-users/2014-February/282338.html
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This patch does a couple of things. It adds a new DEBUG mode where packet
statistics are printed when channels are closed which can be used to track where
packets might be lost in the transcoding chain.
This patch will also print to the kernel log if the AN983 has detected any
errored received packets. Problems of this type are typically system problems,
like when the card is having trouble DMAing packets.
Internal-Issue-ID: DAHDI-1071
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Keeping the transmit descriptor ring shorter reduces the time it takes to send
CSM_ENCAP commands to the transcoding engine when the card is otherwise busy.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
It is only modified under the chanlock anyway.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Simplifies the logic when polling is enabled. No need to worry about any system
factors when scheduling the default kernel timer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Otherwise, if there are many RTP commands queued on the command list, some of
the CSM_ENCAP packets, like ACKS, weren't being sent to the firmware within the
timeout value.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Not only does this make it atomic when moving commands from the
waiting_for_response_list to the command_list if the descriptor is full, it will
also make the entire process of submitting a packet the packet transmission
logic atomic.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was more a holdover when the AN983 interface was brought over from the
voicebus driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When we start the shutdown sequence for a channel, there is no need to submit
any RTP packets that are queued on the command list. Under extreme load with
many backed up RTP packets it was possible to have RTP packets submitted after
the channel shutdown process started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A small percentage of the total packets sent to the DTE ever wait for
completions. This will save on the need to keep the completion around in all the
packets.
Also, since we can use the presence of the completion as the flag whether we
intend to auto free, we can simplify the flags as well.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
While not required by the protocol to the DTE, this does help when debugging the
trace files.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Furthermore, do it as soon as we know we should to prevent the ack from
potentially going out after another CSM_ENCAPS packet on another CPU.
Previously, we would not send ACKS to responses we believed we already responded
to.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Eliminates some cases where there are duplicated packets in the capture if the
hardware descriptor ring was already full.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Makes the channels themselves behave like the supervisor channel. This only
protects the driver in the case the commands were severly backed up, like when
there was high packet loss.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
They are sufficiently protected by the list locks. This also cleans up a case
where the tcp was unlocked after already completing it, which was corrupting the
list.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In case we missed an alert, this will allow for rapid shutdown of Asterisk.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Even if it is duplicated or we don't have an outbound message waiting, we should
ack it so that the firmware does not keep trying to send it to the host.
Otherwise the firmware could get into situations where it was constantly
retrying to send packets for which it did not receive our previous ACK and
exhaust memory.
I was only seeing this on platforms were packets were going missing in the
stream, increasing the probability that the driver would miss early responses.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The kernel log will now contain reports if there are bus errors.
This is a troubleshooting aide on systems with bus issues.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Clarifies that the semaphore was being used as a mutex. Mutexes are also more
efficient and allow better debugging checks.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The ioctls for the debug network interface on the tc400b0 has not been used for
a long time. It is now gone.
This will also allow the sempahore set in the ioctl to be changed into a mutex
which provides enhanced debugging checks.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When an unsolicited alert is received, we'll flag the card as halted so that
commands will not be retried. This is because often times the firmware will no
longer process any commands in this state and the driver will hold processes in
the dstate while waiting to retry the commands.
This is a debugging aide in that it simplies unloading the driver if the card /
driver is currently in a failed state.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The read-line-multiple command was already disabled on the voicebus cards, which
use the same interface, in commit 4de462c3e0. This
does the same thing for the transcoder card and also disables the read line
command.
I've seen this change directly correlated to problems with the AN983 receiving
packets from the onboard DSP on some platforms.
Internal-Issue-ID: DAHDI-1071
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
I've not seen this directly tied to any issue, but it's enabled on the voicebus
cards and so brings the wctc4xxp driver in line.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes regression from bb63d03bba (before
v2.7.0). This failed to set the PCM mask on a CAS span when
DAHDI_AUDIO_NOTIFY was not set.
As the first channel of each xbus would be enabled (for
synchronization), a single call may still have passed.
This patch sets the PCM mask on any CAS channel explicitly.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* It's currently harmless (just re-run the pre/post XPD registrations)
* But it's cleaner this way (as with xbus_register_dahdi_device())
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
XPP devices have implicit support for device registration and
unregistration. Even though it is only used for the legacy (non-hotplug)
configuration case, we still prefer to make it explicit.
This attribute would later allow a simpler implementation of the user
space (xpp-specific) tool dahdi_registration.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
In an Astribank with >= 2 PRI ports, switching from E1 to T1 at run-time
may fail at the DAHDI_CHANCONFIG ioctl on the first channel in a span,
That is, on first run of dahdi_cfg, it fails on second span, on second:
it fails on third span, etc.
The code clears the D-channel information on the DAHDI_CHANCONFIG call
for the first channel in the span.
However The code tested for the global "channo" rather than the per-span
"chanpos" to check for the first channel in the span. This the test
failed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This is to support users who are unable to update to the lastest CentOS 5.x.
There is no change for most users on the latest releases of their distribution.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The timer_list member of the transcoder buffer has not been used for a long
time. Saves some space in the buffer in addition to removing any future
curiosity about what it is for.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
If the memory allocation for the new channel array fails, it would be possible
to call enable_irq() without the corresponding call to disable_irq().
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This fixes a regression introduced first in release 2.9.1 with commit
(7ce8498465 "firmware: Refactor by using build_tools/install_firmware.")
which prevents from installing the firmware in a location other than the system
root.
Bug: https://issues.asterisk.org/jira/browse/DAHLIN-337
Reported-by: Anthony Messina <amessina@messinet.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
[edited the commit message]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* dahdi_registration writes multiple times to:
/sys/bus/astribanks/devices/*/*/span
* In some race cases this resulted in corruption and eventual kernel
panic.
* Until migration to "assigned-spans" is complete:
- Accept and ignore multiple "dahdi registrations" from user-space.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
When the card goes through a reset the PCIe link will be brought down. Some
slots will report this change upstream to the root port which will believe that
the card has been hotplugged out of the system.
This fixes cases on some systems where, during a firmware update, the card gets
removed from the system's logical PCI tree with messages like the following in
the kernel log:
pciehp 0000:00:1c.0:pcie04: Card not present on Slot(259)
pciehp 0000:00:1c.0:pcie04: Card present on Slot(259)
Internal-Issue-ID: DAHDI-1091
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This firmware image is able to handle system conditions that would result in
spans internmittenly going down and recovering.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
These firmware images can handle system conditions that would previously result
in transmitted audio being intermittently silenced and then unsilenced.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This firmware image is able to handle system conditions that would result in
spans going down and then coming back intermittently.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
There are some platforms where the DMA operation to the host does not complete
within the required 50us. When this happens some versions of the firmware will
issue a retry and increment the retry field in the descriptor status word.
Now if this driver is configured in DEBUG mode, the presence of these retries
will be printed to the kernel log as a potential troubleshooting aide.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
There are error conditions that the firmware can detect but cannot recover from
without help from the driver. When firmware detects these conditions the
DESC_IO_ERROR bit will be set in the descriptor header to signal that the driver
should reset the TDM engine on the card. Since this is not due to failure of the
host to service the interrupt in time, it does not make sense to increase
latency when these conditions are detected.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Without this change it's hard to see what is actually running on the card when
the firmware in the flash doesn't match the reported version. This is a
debugging aide.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This allows a .tar.gz file that is normally downloaded from the server to be
checked directly into a test branch. Now when the firmware is being installed,
it can be extracted from any present .tar.gz. Again, this is primarily to
simplify testing.
A nice side effect is that when going from a newer version to an older version,
any stale .bin files in the firmware directory will not be installed into
/lib/firmware, but instead the bin file from the *versioned* .tar.gz will always
be installed. This should reduce problems where you have to run "make
dist-clean" when reverting to an older version that has a firmware change.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is intended to simplify the Makefile and move a large common part into a
subscript. The behavior is the same as it was before.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* We didn't handle proper E1/T1 transitions after device registration.
* Fix SPAN_REGISTERED(xpd):
It now checks for DAHDI_FLAGBIT_REGISTERED as well, as this flag is
set/clear by assign/unassign.
* From set_pri_proto():
- Always free/allocate channels
- Always call dahdi_init_span()
* Improve phonedev_cleanup() safety:
- NULL pointers after free.
- Zero number of channels at the end.
* Refactor channel allocation out of phonedev_init():
- Into phonedev_alloc_channels()
- Also called from xpd_init_span() to prevent duplicated logic.
- And called from set_pri_proto() to prevent our bug.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Commit 74e949c33a exported the module
variable dahdi.auto_assigned_spans. However this is not a good name.
This commit reverts the export and replaces it with a new function to
get the value of the variable.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A fix to 03b3ce1a10: use ktime_get_ts
instead of getnstimeofday to better handle system time changes.
(Shaun Ruffell)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Add a new sysfs attribute to dahdi_device: registration_time
* Records the time of the device's registration with DAHDI.
* Used by dahdi_auto_assign_compat to assign spans by device
registration order when backward compatibility needed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
* Set it to 0 by default (as we use dahdi.auto_assign_spans now)
* Make it readonly (no runtime changes)
* Warn during startup if it was forced to 1
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Instead, use the inverse of dahdi.auto_assign_spans value.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Allow certain older firmwares to delay the hard reset until a full power cycle.
This way we can "preload" newer firmware images, without requiring the user to
physically power off/on their machine.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
This makes the behavior of IRQ misses for these drivers behave the same as the
wcte12xp, wctdm24xxp, and wct4xxp drivers.
Previously irqmisses would never increase. The presence of underruns would still
show up in dmesg as latency bumps.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
These were left over from when the VPM callbacks depended on the different VPM
installed. On the wcte43x this is unnecessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
These were left over from when the VPM callbacks depended on the different VPM
installed. On the wcte43x this is unnecessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was a legacy compile time option that is no longer necessary with the new
series of cards.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
struct dahdi_device.devicetype was set incorrectly in both drivers. This caused
the vpm module to not show up after the device name when reading this field
from a spanstat.
Reported-by: Charles Moye <cmoye@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes potential kernel panic due to accessing invalid memory if passing
invalid local span number to 'spantype' attribute via sysfs.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
It was an oversight to prevent the wcte43x and wcte13xp drivers from using
Message Signaled interrupts during the switch to the wcxb library.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp now has a max_latency module parameter like the wcaxx and wcte43x
drivers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The wcxb library did not do actually use the max_latency member to limit the
maximum latency of the DMA engine.
Now it does.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The infrastructure has been put in place in 2.8.0 for fully dynamic device and
span configuration. This will be the default mode in DAHDI-Linux 2.9.0.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
Previously this was in __dahdi_init_span(). The problem was that
__dahdi_init_span() was only called when a spans' line mode was being changed.
Therefore it was possible to unassign and resassign an analog span and leave it
stuck in the 'NOP' alarm state.
It also make the setting / clearing of DAHDI_ALARM_NOTOPEN symetrical about span
unassignment / assignment in addition to updating the alarm states on all the
channels on the span via the dahdi_alarm_notify() function.
This is a better version of commit 496f817773.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This fixes an issue that affects TDM410 modules when there is not a module
installed in the first port, but there is an FXO module installed in the third
port.
When scaning for QRV modules in the first port, the 3rd port will have the
'hook' struct.qrv set to 0xff. When a QRV module is not detected, that value
will be left, which then maps to an invalid state for both fxo.ring_state and
fxo.battery_state.
The result would be that FXO ports would fail to run the ring detector state
machine since it did not know what the current state was.
Now we'll just reset all the values in struct fxo or struct fxs to the expected
init state.
Internal-Issue-ID: DAHLIN-332
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
A bug introduced in v2.8.0 prevented the recover timing configuration from
being set properly on the hardware. This caused the card to never go into
recovered timing mode.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
drv_attrs was fully removed from the bus structure in upstream commit
e18945b159a1cdbc031f1d3b0b7e515a33bdcbf7 which was merged into 3.13.
This is necessary to compile against linux kernel version 3.13.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
drv_attrs was fully removed from the bus structure in upstream commit
e18945b159a1cdbc031f1d3b0b7e515a33bdcbf7 which was merged into 3.13.
This is necessary to compile dahdi against linux version 3.13.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This resolves issues where, when using internal timing, the first channel of
span 3 has occassional corrupted data in transmit stream.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This extra read eliminates some problems with detecting certain S100M modules.
It is unclear at this time why it is necessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The spi master cur_transfer and cur_msg should only be changed under the
spin_lock for the master. The result is that if running user space tools, like
fxstest, that check registers on the modules, it's possible to have a message
that was not yet complete flagged as completed which would result in a bad read.
This does not affect "normal" operation of the wcaxx driver since interrupts are
not enabled during module detection, and during normal operation all access to
the resgisters is done in the context of the interrupt handler. This would only
be an issue if the interrupt handler was running and register accesses are tried
in user space context on an SMP system.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
For the spans exported by the wctdm24xxp, the channels are not going to change
after they are already registered.
This eliminates a problem when analog spans are unassigned/reassigned and the
not_ready goes negative, thereby causing many warnings in the kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Fixes the following warning when loading the driver:
dahdi: Warning: Span DYN/eth/eth1/00:50:c2:97:92:1d/1 didn't specify a spantype. Please fix driver!
The spantype is intended to be used by the auto configuration tools
(dahdi_genconf, pinned spans, etc..) but dynamic spans, since they are created
directly by dahdi_cfg, never take part in the pre-registration auto
configuration, therefore the span type was never used.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This change will ensure that the oct612x module is unloaded automatically when
/etc/init.d/dahdi stop is run.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* This changeset adds master_span as an attribute of the span's driver:
/sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span
* This is mainly used for debugging.
* Reading from it the master span number (or 0 if there is no master
span).
* Writing a number to it, force specified span to be master
* Existing Alternatives:
- grep "MASTER" from /proc/dahdi/*
- cat /sys/bus/dahdi_spans/devices/span-*/is_sync_master
(Note: commit d8fe2af23d is also Acked-By
Tzafrir Cohen <tzafrir.cohen@xorcom.com>)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Rename as terminology has changed. No change in kernel interface.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* No functional changes.
* Rename the span 'master' to 'master_span' to avoid ambiguity with the
'master' channel.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Create a "ddev" symlink from span's sysfs node to the one of its dahdi
device.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Send the new DAHDI_TOOLS_ROOTDIR and existing DAHDI_INIT_DIR with udev
device events as well.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Passed to udev as DAHDI_TOOLS_ROOTDIR environment variable
* Default is "/"
* Deprecates the parameter initdir:
- Defaults to $DAHDI_TOOLS_ROOTDIR/usr/share/dahdi
- If specified: taken relative to $DAHDI_TOOLS_ROOTDIR
- Setting both parameters explicitly is prohibited.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If the driver is loaded with vpmsupport=0, then it was possible to create a
deadlock situation since the call into __dahdi_ec_chunk might then try to grab
the channel lock while already holding the reglock.
The purpose of grabbing reglock in the DMA routines was to protect the channel
array, which can be changed when linemode is changing. So instead, we'll
completely mask off that interrupt line from all CPUs when potentially changing
the channel array.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The meta block contains specific version and checksum information and allows the
test tools to validate the image in the flash.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Wendell Thompson <wthompson@digium.com>
These new cards are based on a common architecture with the TE133/TE134 as well
as the new analog cards, A4A/A4B/A8A/A8B.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Rus Meyerriecks <rmeyerriecks@digium.com>
* Removed work queue for maint interface as it is not needed in this driver
* Error counters are now accessible through the maint interface
* Consolidated and revised the big maint switch case
* Added loopup/loopdown code transmit logic to E1
* Now supports error/defect insersion
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
The framer appears to continue transmitting a signal after modprobe -r. This
patch will leave the physical framer reset pin asserted to force the chip to
stop transmitting a signal when there is no driver attached.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
Removed all the custom logic and replaced with the common platform wcxb stuff.
There are also changes in here to standardize the function prefix in this
driver to t13x_.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Wendell Thompson <wthompson@digium.com>
Now uses framer interrupt vector polling (in the FPGA interrupt) for
alarm, loopcode, and signaling events eliminating continuous polling.
Now uses timer function for alarm and loopcode debouce, which only
executes during exception conditions.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is a driver for the new line of analog cards that shares a common interface
with the TE133/TE134 and the TE435.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The octasic library is relatively large and is currently separately linked into
both the wcte13xp and wct4xxp libraries. This change moves it out into a
separate loadable module.
The bigest change from the drivers perspectives is that they must provide a
table of callbacks instead of using statically linked Oct6100UserXxxxx functions
to allow the library to communicate with actual parts on the cards.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This works around some issues with older versions of the firmware not
working properly after the linemode is changed via sysfs. Basically the
intent is to simulate redoing a complete driver reload with a new
linemode.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This print happened when the linemode was changed via sysfs, but it didn't
really add much extra information that a user could act on.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
dahdi_genconf currently does not take into account the number of spans
configured for a particular board. Therefore if you have two dual span cards
installed in the system, it could be possible to have something like this in
/etc/dahdi/system.conf:
spans=1,1,...
spans=2,2,...
spans=3,3,...
spans=4,4,...
When what you really want is something like this:
spans=1,1,...
spans=2,2,...
spans=3,1,...
spans=4,2,...
Otherwise, spans 3 and 4 will be configured to not recover the clock from the
span which is most likely NOT what you want.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This eliminates the need for board drivers to always re-report their alarm
states when spans are unassigned and then reassigned.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The driver assumes that the first slot is not empty. If this is not the
case, synchronization will not work.
Fail loading if this assertion does not hold.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Astribank 2.02: a newer model: slight variation of 2.01 (both use E-Main
4). Uses the same USB firmware, has to use a different FPGA firmware as
newer devices cannot be made to work with older 2.01 firmware.
FPGA rev. 11307.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Our user-space previously used the implicit location from the sysfs
device path of the "dahdi_device".
* However:
- Sysfs paths are very limited in length.
- Low-level driver need more control on the location field.
- For example, it need to be persistant for span_assignments.
* We now export explicitly the 'location' field which is managed by
low-level drivers.
* We will use this field as the location in span_assignments.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
init_card_1_30 (FXS modules init script) can now use the new sysfs
interface to set ring settings.
Currently it only overwrite a single register
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
A new SysFS interface for FXS modules (XPDs):
* In /sys/bus/xpds/devices/<ll>:<m>:<n>/fxs_ring_registers
* Reading show current register values for NEON/TRAPEZ/NORMAL
* Modify the table via writing: "<column> <reg> <byte> [<byte>]"
* Example:
echo "NEON 0x33 0x12" > \
'/sys/bus/xpds/devices/00:0:0/fxs_ring_registers'
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
xpp: refactor the FXS module ring settings into separate data structure:
* Update High VBAT initialization in init_card_1_30:
- Take the value used in set_vm_led_mode() (0x34)
- Now we don't need to set it over and over again in set_vm_led_mode()
* Create a unified ring_parameters[] array for all ring registers:
- Columns for 3 ring types (NEON, TRAPEZ, NORMAL)
- Used by new send_ring_parameters() function
* Now the set_vm_led_mode() simply calls send_ring_parameters()
* This cleanup would allow us to change ring parameters at runtime (by
updating the values in these tables).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
With certain pci controllers that support pci hotplug, during the reset
sequence of the fpga, the host controller can get confused about the state of
the card and throw an nmi.
Known affected systems:
HP proliant DL160 & DL360p
Dell poweredge R520
Super Micro X7SPA-HF
This patch attempts to work around that by removing the fpga reset sequence
from the driver startup, then setting various control registers to known
starting state values.
This patch removes the field upgradeable firmware logic temporarily for the
te133 card to prevent fpga reset.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* If userspace would run
modprobe xpp_usb && cat /sys/bus/astribanks/devices/xbus-00/waitfor_xpds
it would return immediately rather than wait for the Astribank to
initialize.
* We sometimes managed to read before getting the reply from the
astribank.
* Now we don't trust unit count at such an early stage.
* Instread we wait for the Astribank to reach a stable state (READY or FAIL)
before finish waiting for this astribank.
Internal-Issue-ID: Xorcom-1502
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* In old kernels (e.g: 2.6.18) sysfs file names must be shorter
then KOBJ_NAME_LEN.
* Longer names are truncated and this leads to duplicate names
which fails device_register()
Examples: "dahdi!channels!10!10" is truncated to "dahdi!channels!10!1"
* The fix shorten the names and make them fixed length. Example:
"dahdi!chan!010!010"
* It seems no current userspace tools rely on that name or on
/dev/dahdi/channels .
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This was causing inconsistancies with dahdi_scan showing an "UNCONFIGURED" span
in the "RED" state.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes a regression introduced in 2.7.0 in commit
(da8b96d725 "dahdi: Remove unused 'rxbufpolicy'
and 'rxdisable' from dahdi_chan.") when CONFIG_DAHDI_NET is defined in
include/dahdi/dahdi_config.h.
rxbufpolicy was always hardcoded to immediate policy and was removed from the
channel structure. There is no longer any need to set it in dahdi_net_open.
Reported-by: Dave Fullerton <dfullertasterisk@shorelinecontainer.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If system conditions prevent the card from loading the firmware without
touching all the descriptors in the ring, it's possible for
wctc4xxp_cleanup_descriptor_ring to attempt cleanup of a command that was never
submitted resulting in the following BUG.
wctc4xxp 0000:02:0a.0: Failed to load firmware.
BUG: unable to handle kernel paging request at c109556c
IP: [<f9faa83e>] wctc4xxp_cleanup_descriptor_ring+0x8c/0x148 [wctc4xxp]
Reported-by: Xavier Carcelle <xcarcelle@avencall.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
This is needed to compile against Linux 3.10.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
[tzafrir.cohen@xorcom.com: fixed passing /proc/xpp/XPD/summary xbus number]
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
This is needed to compile against Linux 3.10.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
create_proc_entry() was deprecated and replace with proc_create_data() since
it's open to a race condition where the proc entry is visible before the file
operations have been set for it.
The PDE() macro also is no longer available as of Linux 3.10 and is replaced
with PDE_DATA() to get the data member from a proc entry. This is due to the
fact that 'struct proc_dir_entry' is now private to the proc_fs.
This commit changes the core of DAHDI and also introduces proc_create_data() and
PDE_DATA() for older kernels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
* This will prevent *ANY* polarity reversal reporting to DAHDI.
* False by default.
* Used in some rare sites with really bad line quality.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
If a span was fully configured before unassigning and reassigning to a new span
type it was possible for stale values to be present in the register. When
switching from T1 to E1 via the spantype sysfs attribute this could result in a
test pattern being written.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If a card stops generating interrupts for any reason, it can take awhile to
unload the driver while waiting for the commands to timeout. Now if there is a
problem, immediately set a bit that the card is failed so that no new commands
will be submitted.
Also, do not free and commands in submit since all commands are freed in get
results now. This prevents list/memory corruption when commands time out.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When spans are unassigned, dahdi_span_ops.shutdown was called, but the RUNNING
flag was never cleared. Now make sure all calls to the shutdown span ops
callback are the same.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If you have a multiple span system configured for t1 mode, and you try to change
only the first span from t1 to e1 via sysfs, you could get an error in the
kernel log about trying to create duplicate channel.
The problem is that the check for whether there was enough room for the all the
channels of the switched span was wrong.
Reported-by: James Brown <jbrown@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This brings the wcte12xp driver in line with the wct4xxp driver. It also
eliminates the chance that the local side will errouneously go into loopup when
switched from E1 to T1 mode via the spantype sysfs attribute.
Internal-Issue-ID: DAHDI-1038
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This adds definitions for bool and pr_fmt which are needed when compiling
against vanilla 2.6.18.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In 2.6.2 I introduced an error in (41639330a "wctdm24xxp: Eliminate chance for
channel to be stuck in RED alarm.") which would get an FXO stuck in detecting an
ONHOOK event from the remote side. An FXO port could go into the
BATTERY_DEBOUNCING_LOST_ALARM state and then back to the BATTERY_PRESENT state
without sending the dahdi_hooksig up to Asterisk. Therefore, Asterisk would
never detect the state changes needed for a remote side disconnect.
This change adds two more states, BATTERY_DEBOUNCING_PRESENT_FROM_LOST_ALARM and
BATTERY_DEBOUNCING_LOST_FROM_PRESENT_ALARM so that the state machine does not
miss any needed transitions when going back to BATTERY_PRESENT or BATTERY_LOST
regardless of why the debounce was started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The channels now have embedded 'struct devices' that contain a device_private
pointer in which to store the device private data. When a device is
unregistered in the system the device privata data is freed by the device core,
even though the chan_release function doesn't free the memory
associated with the device, So when dev_set_drvdata() is called,
it's writing into freed memory.
We also need zero out the embedded struct device before registration,
since we do not have any guarantee that it points to valid memory (or, if a
channel was unregisterd with sysfs, and then reregistered without being cleared
out). Otherwise the core could try to use the previously freed private
data again.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If a user switches linemode with sysfs, the VPM would never switch the
companding mode to alaw, and the result would be extreme static on all channels
of the span when the VPM is enabeld.
Now if the deflaw of the span has changed when an echocan is created, the
companding mode of the VPM channel is changed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Soon there will be more than one driver in the source tree that will want to use
these files. Compiling it as a library speeds the build since it won't have to
be built for each driver that wants to link it in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Some of the card callbacks needed maintstat set when processing loopup codes
from the remote side. This change is a modification of commit: (6c02c3c
"dahdi-base: Minor maint mode error")
Without this change cetain cards would not properly process the loopup /
loopdown codes (I know I should have more specific information here but the
details escape me at the moment).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Adds support for setting a value of 3 to the module parameter
caller_id_style: passthrough - always pass and don't try to emulate
DTMFs.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
An unset conditional compile flag was triggering the unused variable compile
warning. Added the condition around the variable define.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes up the kbuild to work with compiling OSLEC from the kernel source. See
HOWTO here: http://forums.digium.com/viewtopic.php?t=67164
Internal-Issue-ID: DAHLIN-317
Reported-By: Vladimir Mikhelson
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Otherwise, it's possible for a link to remain in use if a process quits without
unlinking the conferences. Now when all the channels are removed from the
conference, any links are also cleaned up.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is mostly a revert of commit r9463. If you need to use DAHDI_CONFLINK
ioctl, make sure to define CONFIG_DAHDI_CONFLINK in
include/dahdi/dahdi_config.h. Apparently there were some users of CONFLINK out
there still.
It's a compile time option now since most users won't need to run the test for
conflinks in the hot-path that is the process_masterspan function.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Tested-by: Ted Gerold <ted@twg.org>
Trades the memory of a file_operations structure to eliminate some tests in the
timer operations.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
On SMP systems there isn't a need for all dahdi timers to
synchronize on dahdi_timer_lock. Instead give each timer it's own
lock to synchronize with process_timers and use dahdi_timer_lock to
protect the global list of locks.
Also, the dahdi_timers list now only contains timers that are set to
fire. This eliminates a test for each timer in the hot path of the
process_masterspan context.
Reduces system load on many-core systems which are heavy users of
DAHDI timers.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The Big Kernel Lock removal is no longer experimental so we can eliminate the
call to lock_kernel when calling unlock_ioctl.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
There was a code patch where it was possible to get stuck in RED ALARM on a
channel when debouncing the battery states. The state transitions would look
like this:
BATTERY_PRESENT -> BATTERY_DEBOUNCING_LOST -> BATTERY_DEBOUNCING_LOST_ALARM --
(send alarm up to asterisk) --> BATTERY_LOST -> BATTERY_DEBOUNCING_PRESENT ->
BATTERY_DEBOUNCING_PRESENT_ALARM -> BATTERY_DEBOUNCING_LOST -> BATTERY_PRESENT
In the above sequence there was never any transition from
BATTERY_DEBOUNCING_PRESENT_ALARM to BATTERY_PRESENT so the alarm to Asterisk was
never cleared and the channel stayed stuck.
Now when you loose battery when in the BATTERY_DEBOUNCING_PRESENT_ALARM go all
the way back to the BATTERY_LOST state instead of the BATTERY_DEBOUNCING_LOST
state so that all the events are properly sent up.
This fixes a regression introduced in 2.6.0 with commit (r10169 "wctdm24xxp: Use
interval for debouncing FXO battery." 874b76bd22).
Internal-Issue-ID: DAHDI-1019
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The logic to check for battery lost and battery present were using different
time bases. One was using jiffies and the other was using framecount. Since
framecount is always in milliseconds, let's use that to stay consistent.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
hfc_decode_st_state() will be called from interrupt context when the debug flag
is set to 32. Therefore, must use GFP_ATOMIC when allocating memory.
Only affects the wcb4xxp driver when called with particular debug flags set.
Internal-Issue-ID: DAHLIN-314
Reported-by: Gerald Schnabel
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is necessary to prevent a crash when opening files by the new
device files, which do not have a valid file_operations structure.
This fixes a problem does not exist in any releases of DAHDI.
Since none of the existing tools or applications open files from the
new location of /dev/dahdi/channels/<span>/<offset>, this wasn't
seen until just recently.
Reported-by: Ted Gerold <ted@twg.org>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Without digging into the specifics, it looks like Red Hat Linux 5.9
removed the hex_asc definition that was previously used to determine
if the bool definition was backported.
We can simply use the RHEL_RELEASE_CODE now since we do not support any
releases before the 5 series now.
Reported-By: Vladimir Mikhelson
Internal-Issue-ID: DAHLIN-312
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
It's wrong (and explicit oops with kernel >= 2.6.19) to set both
bus and class for the same device. But setting the class is not needed
in order to create a device. So just remove our dynamic devices from the
dahdi_class. It will only contain the fixed-named devices.
This fixes regression from cb4e4d0068.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The driver iterates through all the spans on a given device during assignment,
checking for unassigned spans, but it was erroneously testing the span on which
assigned was called.
This just removes some unexpected behavior and provides a slight performance
increase on load and does not impact the functionality of the driver as far as
I'm aware.
Reported-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Eliminates the following warning from sparse:
drivers/dahdi/dahdi-sysfs-chan.c:50:29: error: dubious one-bit signed bitfield
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This allows timingslips to be reset along with the other counters and clarifies
the intended use.
This came up when Doug Bailey asked why he couldn't use dahdi_maint to clear
timing slips in addition to the other counters.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* Channels have their own dynamically allocated major number
* No arbitrary limit of minor < 250 (no collision with /dev/timer, etc)
* We still have arbitrary limit of channo < DAHDI_MAX_CHANNELS
(should be raised?)
* FIXME: need to check to FIXME's
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
* Added minimal infrastructure:
- A 'chan_device' member to struct dahdi_chan
- An empty 'device_attribute' array
- A 'bus_type' with its methods
- A 'device_driver' with its methods
- Initialization/Cleanup code
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
This resolves an issue with a Glenayre GL3000 Paging Terminal with v8.000
software. The Glenayre would change both A and B bits to signal on/off hook
states, but there were a couple of milliseconds between when those bits changed.
This resulted in DAHDI generating an on-hook event to Asterisk before generating
the off-hook event and therefore Asterisk terminated the call prematurely.
Looking the A and B bits before this patch:
Asterisk (AB) Glenayre (AB)
00 00 Both sides on-hook
11 00 Asterisk goes off hook to sieze line.
11 01 Glenayre starts going-offhook. On-hook event
sent to Asterisk from drivers since bits
changed but ABIT was still 0.
11 11 Glenayre finishes going off-hook. Off-hook
event sent to Asterisk since ABIT changed
from 0 to 1.
00 11 Asterisk, processes on-hook event and goes
on-hook itself to release line.
00 00 Glenayre releases line. Call fails.
After this patch:
Asterisk (AB) Glenayre (AB)
00 00 Both sides on-hook
11 00 Asterisk initiates call
11 01 Glenayre starts handling call. No event is
sent to Asterisk since only ABIT is checked.
11 11 Glanayre finishes going off-hook. Call
proceeds normally.
Internal-Issue-ID: DAHDI-1009
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
dahdi_dynamic now always calls the flush function in softirq context so packet
flushing no longer needs to be pushed off to process context since interrupts
are enabled.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Don't run the pre- and post-unregister hooks on a non-phone XPD
(practically: the echo canceller). This fixes a panic with manual
'dahdi_registertion off' as it is now called for the whole device
(regression of 2.6.x).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10735 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since r10290 "wct4xxp: Add support for TE820 and VPMOCT256." [1],
the TONEDETECT ioctl was not calculating the VPM channel correctly
on non TE820 cards. This fixes a regression first introduced in
2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10290
Internal-Issue-ID: DAHLIN-302
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10733 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since r5021 [1], first released in DAHDI-Linux 2.2.0, it's been impossible for
user space to change the rxbufpolicy. This hasn't caused any problems and it's
safe to remove a few more of the vestiges of the rxbufpolicy from the driver.
This streamlines the code path in a few places and saves 8 bytes from the size
of struct dahdi_chan.
The user visible parts are maintained and will indicate
DAHDI_POLICY_IMMEDIATE, like it has since 2.2.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=5021
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10730 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since r10683 "convert span->spantype to enumerated type" [1] the spantype was
changed from a string provided by the board drivers to an enumerated type that
is handled by the core of DAHDI. This was done to simplify the task of
dahdi_genconf since there is only one place to look for the valid strings that
can be exported in sysfs.
This eliminates the following warning on driver load:
Warning: Span %s didn't specify a spantype. Please fix driver!
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10683
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10729 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Not configuring all the spans on an octal card can result in some of the
spans not working in clear channel modes.
Now ensure that all spans receive a default configuration regardless how
they are configured from user space.
Internal-Issue-ID: DAHLIN-289
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10728 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Internally in DAHDI there is always a hardware echocan factory registered and
available. Having this factory always registered allows for DAHDI to work in a
backward compatible fashion. Namely, by default DAHDI will always use a hardware
echocan if one is available unless 'hwec_overrides_swec' dahdi module parameter
is set to 0 on load. However, if there were no real hardware echocans available
in the system dahdi would still report "Echo Canceller(s): HWEC" in the
dahdi_cfg -v output since the hwec factory is always there.
After this change dahdi_cfg will no longer report HWEC as one of the available
echocans if there isn't a physical span present that actually has a hardware
echocan.
Internal-Issue-ID: DAHLIN-300
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10727 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes a regression introduced in commit r10186 "wctdm24xxp: Use time
interval for debouncing FXO ring detect." [1] which was first released in
DAHDI-Linux 2.6.0. This only affects users with analog trunks whose providers do
not present 4 polarity reversals on the ring signals. The reporter of this issue
is based in South Africa.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168
In prior versions, the ring detector did not check for polarity reversals, only
the presence of ringing voltage unless fwringdetect or neonmwi_monitor mode was
set, and even when one of those modes were set, the driver only needed two
reversals to validate a ring. This commit allows the driver to always stay in
fwringdetect mode but restores the requirement for only two reversals.
Also included in this commit is a change to ensure that ringing is not reported
when debouncing lost battery which can happen when voltage is swinging through
0.
Reported-and-Tested-by: Jaco Kroon <jaco@uls.co.za>
Internal-Issue-ID: DAHLIN-298
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10719 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The previous maint state was saved regardless if the base driver returned an
error or not. This caused strange behavior in dahdi tools. Moved the maint
state save to after the switch case to reflect this.
https://issues.asterisk.org/jira/browse/DAHDI-984
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10718 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes an (embarrassing) error in t1_check_sigbits in the previous commit
where I was writing pass the end of an array on the stack.
Now instead of using an array on the stack, of which all elements were not used,
the pending commands are now stored on a list. I also removed the automatic free
of commands from __t1_getresults and now the function that allocated the command
now frees them.
I believe this will be less error-prone going forward.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10700 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The frequency that the RBS registers were polled was too slow to catch the pulse
dialing digits. The result was that often times dahdi would generate WINK events
instead of PULSEDIGIT events.
This speeds up the rate at which the registers are checked from 100ms to 33ms
and also makes the process of checking the registers quicker by queing up all
the reads at once.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10699 a0bf4364-ded3-4de4-8d8a-66a801d63aff
To enable J1 mode previously one would configure the card in T1 mode and then
set the j1mode module parameter. Now "modprobe wcte12xp default_linemode=j1"
will work like the other linemodes globally for all cards manged by this driver.
J1 can also be set on a card-by-card basis in sysfs.
Also move pr_fmt to top of file so pr_xxx macros print the module name as
intended.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10696 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* UMH_WAIT_PROC semantics (and value) was changed from enum to
a bitmask (via #define)
* This constant was missing from kernels older than 2.6.23
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@10692 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* This is a minimal convertion -- everything compiles and looks OK.
* We print a warning for spans registering without a spantype.
* Low-level drivers may later want (but not required)
to fold their internal representations to this canonical
representation -- it will save code and make it more readable.
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@10683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I failed to compile test r10661 and introduced a typo when fixing a
checkpatch.pl warning.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10662 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a port of the functionality in the wctdm24xxp driver to support power
savings modes. Specifically, if the the network side of a BRI spans deactivates
the span to save power, the B410P previously automatically activated it again.
Now, if persistentlayer1=0 module parameter is set, the span will be allowed to
stay deactivated until layer two has a message to send on the dchannel.
This patch does not change any of the default behavior of the B410P driver and
the defaults for the persistentlayer1 option is inconsistent with that of the
B400M modules in the wctdm24xxp driver.
Internal-Issue-ID: ABE-2845
From: Matthew Fredrickson <creslin@digium.com>
[ Minor formatting, exposed the persistentlayer1 as module parameter, changed
defaults for teignorered, alarmdebounce, and persistentlayer1 to match current
defaults in wcb4xxp driver ]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10661 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Previous commit (r10649) 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>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10652 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>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10649 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Print a warning message that it may be a GPL violation to redistribute these
binaries if the firmware for the VPMOCT032/64/128/256 is compiled in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10646 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>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10640 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irq' field was removed from dahdi_span in r10276 "dahdi: Remove
dahdi_span.irq and move dahdi_span.irqmisses into dahdi_device." [1]
which was first released in dahdi-linux 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10276
Reported-by: Pavel Selivanov
Internal-Issue-ID: DAHLIN-278
Patches: hdlc.patch by Pavel Selivanov (license #5420)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10634 a0bf4364-ded3-4de4-8d8a-66a801d63aff
