A fresh modprobe and dahdi_cfg would cause a temporary green alarm state on the
driver for a second while the alarm debounced into RED. New logic keeps the
spans alarm state as NONE during the unconfigured state, but sets the alarm
state to RED after the framer reset in the startup logic.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
If dahdi_span_ops.spanconfig is called multiple times in a row (like when
running dahdi_cfg; dahdi_cfg ) the tx signaling bits would go through a spurious
state that some far side devices would respond to.
Now, if the dahdi_span_ops.spanconfig callback is called, and the configuration
matches the existing configuration, we will not touch the framer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).
This is because the wcte13xp driver only updates the alarm state when the framer
reports that the span alarm has changed. Therefore, unless the framer goes
through an alarm transition, the fact that channels are opened was never noticed
by alarm handling routine.
Now check the alarm state directly when the first channel is opened, and the
last channel is closed.
Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@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>
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>
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>
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>
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>
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>
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>
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>
This was causing inconsistancies with dahdi_scan showing an "UNCONFIGURED" span
in the "RED" state.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
