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>
