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>
/usr/lib/hotplug/firmware is an old location not used since the move
from the old hotplug system. We no longer need to support it. No need to
keep two copies of the firmware files.
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.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>
Normally the board drivers should define this, but if they do not we will
provide a suitable default. This allows compilation with vanilla Linux 2.6.18.
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>
