[zaptel-commits] kpfleming: branch kpfleming/battery_alarms r3962 - in /team/kpfleming/battery...

SVN commits to the Zaptel project zaptel-commits at lists.digium.com
Fri Mar 7 09:22:59 CST 2008


Author: kpfleming
Date: Fri Mar  7 09:22:59 2008
New Revision: 3962

URL: http://svn.digium.com/view/zaptel?view=rev&rev=3962
Log:
resolve, reset

Added:
    team/kpfleming/battery_alarms/kernel/xpp/utils/xpp_timing
      - copied unchanged from r3958, branches/1.4/kernel/xpp/utils/xpp_timing
Modified:
    team/kpfleming/battery_alarms/   (props changed)
    team/kpfleming/battery_alarms/kernel/xpp/.version
    team/kpfleming/battery_alarms/kernel/xpp/Changelog_xpp
    team/kpfleming/battery_alarms/kernel/xpp/Kbuild
    team/kpfleming/battery_alarms/kernel/xpp/README.Astribank
    team/kpfleming/battery_alarms/kernel/xpp/calibrate_slics
    team/kpfleming/battery_alarms/kernel/xpp/card_bri.c
    team/kpfleming/battery_alarms/kernel/xpp/card_fxo.c
    team/kpfleming/battery_alarms/kernel/xpp/card_fxs.c
    team/kpfleming/battery_alarms/kernel/xpp/card_global.c
    team/kpfleming/battery_alarms/kernel/xpp/card_pri.c
    team/kpfleming/battery_alarms/kernel/xpp/firmwares/FPGA_1141.hex
    team/kpfleming/battery_alarms/kernel/xpp/firmwares/FPGA_1151.hex
    team/kpfleming/battery_alarms/kernel/xpp/firmwares/FPGA_FXS.hex
    team/kpfleming/battery_alarms/kernel/xpp/init_card_3_29
    team/kpfleming/battery_alarms/kernel/xpp/utils/Makefile
    team/kpfleming/battery_alarms/kernel/xpp/utils/astribank_hook
    team/kpfleming/battery_alarms/kernel/xpp/utils/xpp.rules
    team/kpfleming/battery_alarms/kernel/xpp/utils/xpp_fxloader
    team/kpfleming/battery_alarms/kernel/xpp/utils/zapconf
    team/kpfleming/battery_alarms/kernel/xpp/utils/zconf/Zaptel/Hardware/PCI.pm
    team/kpfleming/battery_alarms/kernel/xpp/utils/zconf/Zaptel/Span.pm
    team/kpfleming/battery_alarms/kernel/xpp/xbus-core.c
    team/kpfleming/battery_alarms/kernel/xpp/xbus-core.h
    team/kpfleming/battery_alarms/kernel/xpp/xbus-pcm.c
    team/kpfleming/battery_alarms/kernel/xpp/xbus-pcm.h
    team/kpfleming/battery_alarms/kernel/xpp/xbus-sysfs.c
    team/kpfleming/battery_alarms/kernel/xpp/xdefs.h
    team/kpfleming/battery_alarms/kernel/xpp/xframe_queue.c
    team/kpfleming/battery_alarms/kernel/xpp/xpp_usb.c
    team/kpfleming/battery_alarms/kernel/xpp/xpp_zap.c
    team/kpfleming/battery_alarms/kernel/xpp/xproto.c
    team/kpfleming/battery_alarms/kernel/zaptel-base.c

Propchange: team/kpfleming/battery_alarms/
------------------------------------------------------------------------------
    automerge = si, senor

Propchange: team/kpfleming/battery_alarms/
------------------------------------------------------------------------------
Binary property 'branch-1.2-merged' - no diff available.

Propchange: team/kpfleming/battery_alarms/
------------------------------------------------------------------------------
--- svnmerge-integrated (original)
+++ svnmerge-integrated Fri Mar  7 09:22:59 2008
@@ -1,1 +1,1 @@
-/branches/1.4:1-3953
+/branches/1.4:1-3961

Modified: team/kpfleming/battery_alarms/kernel/xpp/.version
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/.version?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/.version (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/.version Fri Mar  7 09:22:59 2008
@@ -1,1 +1,1 @@
-trunk-r5254
+trunk-r5512

Modified: team/kpfleming/battery_alarms/kernel/xpp/Changelog_xpp
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/Changelog_xpp?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/Changelog_xpp (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/Changelog_xpp Fri Mar  7 09:22:59 2008
@@ -1,3 +1,57 @@
+Mon,  3 Mar 2008 Oron Peled <oron at actcom.co.il> - xpp.r5512
+  * Build:
+    - Zaptel >= 1.4.9 is migrating to storing kernel stuff in zaptel/kernel/*
+    -  We conditionally use old/new directory scheme:
+       In xpp/Kbuild and xpp/utils/Makefile use ZAP_KERNEL variable, so it's
+       not confused with ZAPTEL_DIR (which appears in zaptel/Makefile as well).
+    - Fix compile warnings on 64 bit systems.
+    - Compile fixes for kernel-2.6.24
+  * UDEV:
+    - /etc/udev/rules.d/xpp.rules now uses XPP_INIT_DIR to find astribank_hook.
+    - astribank_hook: Modify to do nothing. Add some documentation.
+  * Autoconfiguration -- zapconf:
+    - Don't fail zapconf et.al. if no config file was found.
+    - Skip the 'IRQ Missing:' line in /proc/zaptel/nnn for wcte1xp(?).
+    - Add some newer Digium cards to our hardware inventory.
+    - Partially handle cases where the /proc/zaptel strings does not contain
+      info about E1/T1/J1 or NT/TE.
+  * Better SYNC:
+    - Finer tuning of PLL (New firmware).
+    - Change calculation algorithm of sync offset. It now copes better
+      with the variance in USB frame reception timing.
+    - Statistics:
+      . The view of results was moved from /proc/xpp/XBUS-*/summary to
+        a new /sys/bus/astribanks/devices/xbus-*/timing and enhanced.
+      . A new xpp_timing script shows all astribanks.
+      . A new write only /sys/bus/astribanks/devices/xbus-*/cls is
+        used to clear statistics. Eventually, clearing of XBUS related
+        statistics should be done here. One that was migrated is the
+        clearing of 'PCM [TR]X:' numbers currently appearing in
+        /proc/xpp/XBUS-*/summary (they should be moved too later).
+    - Shorten the strings representation sync_mode ("SYNC_MODE_AB" -> "AB")
+      adapted their use in printk and /proc so the text is clear.
+    - Added a command line parameter xpp.disable_pll_sync to stop all
+      adjustments command to AB (calculations still continue as usual).
+  * PRI:
+    - 4 port support
+    - set clocking master span via ztcfg, like other zaptel devices.
+  * FXO:
+    - Fix false hangups in some countries (voltage fluctuations).
+    - Some countries send caller-id before first ring.
+      Added code to handle caller-id PCM pass through according to
+      a new command line parameter (xpd_fxo.caller_id_style).
+    - No longer sends an event on zt_open. See #12160 .
+  * Misc:
+    - Adapt to zaptel-1.4.8 and above ztscan: added fields returend by
+      new ZT_SPANSTAT_V2 ioctl()
+    - Document sysfs and waitfor_xpds.
+    - Miscelaneous optimizations and bugfixes.
+    - Remove deprecated pcm_tasklet parameter. The rx_tasklet parameter has
+      replaced it a long time ago.
+    - Add RX_CMD counter to /proc/xpp/XBUS-*/summary
+    - Unclutter some of the usb disconnect messages.
+    - xpp_usb: minor preformance improvements in receive.
+      Expose the number of pending receive URB's in /proc/xpp/XBUS-*/xpp_usb
 Thu Jan 10 2008 Oron Peled <oron.peled at xorcom.com> - xpp.r5254
   * Improved polarity reversal hangups in FXO (r5194).
     Fixed false detection of polarity reversals.

Modified: team/kpfleming/battery_alarms/kernel/xpp/Kbuild
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/Kbuild?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/Kbuild (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/Kbuild Fri Mar  7 09:22:59 2008
@@ -1,11 +1,11 @@
 ifdef SUBDIRS
-  ZAPTEL_DIR	= $(SUBDIRS)
+  ZAP_KERNEL	= $(SUBDIRS)
 else
-  ZAPTEL_DIR	= $(M)
+  ZAP_KERNEL	= $(M)
 endif
 
 EXTRA_CFLAGS	=	$(XPP_LOCAL_CFLAGS)	\
-			-I$(ZAPTEL_DIR)	\
+			-I$(ZAP_KERNEL)	\
 			-DDEBUG			\
 			-DPOLL_DIGITAL_INPUTS	\
 			-DWITH_ECHO_SUPPRESSION	\
@@ -14,13 +14,13 @@
 			-g
 			#
 
-ifneq	(,$(shell grep -w echo_can_state_t $(ZAPTEL_DIR)/zaptel.h))
+ifneq	(,$(shell grep -w echo_can_state_t $(ZAP_KERNEL)/zaptel.h))
 EXTRA_CFLAGS	+= -DZAPTEL_EC_TYPEDEF
 endif
 
 obj-m		+= xpp.o xpd_fxs.o xpd_fxo.o xpd_pri.o
 
-HAS_BRISTUFF		:= $(shell cpp $(CPPFLAGS) -dM $(ZAPTEL_DIR)/zconfig.h | sed -n 's/^.*CONFIG_ZAPATA_BRI_DCHANS/y/p')
+HAS_BRISTUFF		:= $(shell cpp $(CPPFLAGS) -dM $(ZAP_KERNEL)/zconfig.h | sed -n 's/^.*CONFIG_ZAPATA_BRI_DCHANS/y/p')
 
 # Build only supported modules
 ifneq	(,$(filter y m,$(CONFIG_USB)))

Modified: team/kpfleming/battery_alarms/kernel/xpp/README.Astribank
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/README.Astribank?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/README.Astribank (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/README.Astribank Fri Mar  7 09:22:59 2008
@@ -4,7 +4,7 @@
 $Revision$, $Date$
 
 This file documents the Zaptel drivers for the Xorcom Channel Bank.
-The drivers reside in a separate subdirectory, xpp/ .
+The drivers reside in a separate subdirectory, kernel/xpp/ .
 
 It is generally a more technical document than the 
 http://www.xorcom.com/documentation/manuals/[Astribank User Manual]
@@ -19,6 +19,10 @@
 
 Building drivers
 ~~~~~~~~~~~~~~~~
+Apart from the standard Zaptel build requirements, you also need libusb
+development headers to build the fpga_load firmware loader. This is
+typically the package libusb-dev or libusb-devel .
+
 On zaptel 1.2 you will need to run the following extra step to build the
 Astribank drivers, apart from the standard 'make':
 
@@ -53,7 +57,7 @@
 
 The value XPP_PRI_SETUP in the init configuration file (see example
 below) can be used to change those defaults. This value is a
-whitelist-separated list of conditions. When a port is initialized it 
+whitespace-separated list of conditions. When a port is initialized it 
 checks those conditions and uses the firs one that matches.
 
 Match expressions may be:
@@ -61,6 +65,7 @@
 - NUM/XBUS-mm/XPD-nn		To identify by bus number
 
 Match expressions may contain "wildcards":
+
 - * matches zero or more characters.
 - ? matches one charater
 - [xyz] - any of 'x', 'y', or 'z'.
@@ -458,98 +463,182 @@
 ---------------
 The following commands provide useful information for debugging:
 
-* Check USB level status. You can use one of the following utilities for it:
+lsusb Test
+~~~~~~~~~~
+Check USB level status. You can use one of the following utilities for it:
 
   zaptel_hardware -v
        or
   lsusb | grep e4e4
 
-  - Look for the USB Product ID (the second number after e4e4).
-  - If you see *11x2* (e.g: 1152)- the FPGA firmware has been loaded.
-    Move on.
-    zaptel_hardware will also show you some more details if the driver
-    is loaded while the lsusb will just list the device.
-  - If it shows something as product ID *11x0* - the USB firmware is not
-    loaded. Maybe you need to run fxload. Or maybe just unplug and plug again
-    the device. Also make sure that you have fxload installed.
-  - If lsusb shows the Product ID as *11x1* - only the USB firmware is loaded 
-    and not the FPGA firmware is loaded. If this is still the case after 
-    a while - either the firmware loading has failed or you don't have
-    fpga_load. Make sure you have libusb-dev(el) installed when
-    building Zaptel.
-  - It should list all of your Astribank devices. If it doesn't (for
-    more than period of time needed for the initial firmware
-    loading) - Check that the Astribank is connected indeed.
-
-* Check if the Astribank spans are registered in Zaptel
+- Look for the USB Product ID (the second number after e4e4).
+- If you see *11x2* (e.g: 1152)- the FPGA firmware has been loaded.
+  Move on.
+  zaptel_hardware will also show you some more details if the driver
+  is loaded while the lsusb will just list the device.
+- If it shows something as product ID *11x0* - the USB firmware is not
+  loaded. Maybe you need to run fxload. Or maybe just unplug and plug again
+  the device. Also make sure that you have fxload installed.
+- If lsusb shows the Product ID as *11x1* - only the USB firmware is loaded 
+  and not the FPGA firmware is loaded. If this is still the case after 
+  a while - either the firmware loading has failed or you don't have
+  fpga_load. Make sure you have libusb-dev(el) installed when
+  building Zaptel. After you have installed it, you may need to re-run
+  ./configure .
+- It should list all of your Astribank devices. If it doesn't (for
+  more than period of time needed for the initial firmware
+  loading) - Check that the Astribank is connected indeed.
+
+
+Zaptel Registration
+~~~~~~~~~~~~~~~~~~~
+Check if the Astribank spans are registered in Zaptel
 
   zt_registration
 
-  - This should give useful results after the drivers have identified
-    and your devices are initialized.
-  - It should list all Astribank XPDs. For each of them it should write
-    "on" or "off". If the registration status is "off", then it means that
-    the span has not been registered in Zaptel and therefore can not be used
-    yet.
-  - Registration is normally done as part of `/etc/init.d/zaptel start`.
-    If you want to register the spans manually, then run command:
-    `zt_registration on` .
-  - Disabling of the automatic Astribank spans registration give you full
-    control on the order of Zaptel spans. See the module parameter
-    **zap_autoreg** for the further details.
-
-* Check the Zaptel information:
-  You can get some information regarding Zaptel channels by running one of the
-  following commands:
+- This should give useful results after the drivers have identified
+  and your devices are initialized.
+- It should list all Astribank XPDs. For each of them it should write
+  "on" or "off". If the registration status is "off", then it means that
+  the span has not been registered in Zaptel and therefore can not be used
+  yet.
+- Registration is normally done as part of `/etc/init.d/zaptel start`.
+  If you want to register the spans manually, then run command:
+  `zt_registration on` .
+- Disabling of the automatic Astribank spans registration give you full
+  control on the order of Zaptel spans. See the module parameter
+  **zap_autoreg** for the further details.
+
+
+Zaptel Level Information
+~~~~~~~~~~~~~~~~~~~~~~~~
+You can get some information regarding Zaptel channels by running one of the
+following commands:
 
     lszaptel
        or
     cat /proc/zaptel/*
 
-  - Those two are almost the same. The lszaptel produced more correctly sorted
-    output if you have more than 10 spans, and also make the output listing
-    looks a little bit nicer.
-  - You can see if your Zaptel spans and channels were loaded, if
-    they were configured by ztcfg and if they are in use (typically by
-    Asterisk).
-    For example:
-     Not configured Astribank FXS channel will be displayed as:
-
-       42 FXS
-
-     When a channel has been configured with *ztcfg* (that applies
-      /etc/zaptel.conf), you will see an extra column for the signalling
-      type of the channel. The same channel after it has been configured:
-
-       42 FXS        FXOKS
-
-     If a program (which is typically Asterisk) uses it, you'll see:
-
-       42 FXS        FXOKS      (In use)
-
-* Check the Asterisk information:
-
+- Those two are almost the same. The lszaptel produced more correctly sorted
+  output if you have more than 10 spans, and also make the output listing
+  looks a little bit nicer.
+- You can see if your Zaptel spans and channels were loaded, if
+  they were configured by ztcfg and if they are in use (typically by
+  Asterisk).
+  For example:
+  Not configured Astribank FXS channel will be displayed as:
+
+     42 FXS
+
+- When a channel has been configured with *ztcfg* (that applies
+  /etc/zaptel.conf), you will see an extra column for the signalling
+  type of the channel. The same channel after it has been configured:
+
+    42 FXS        FXOKS
+
+- If a program (which is typically Asterisk) uses it, you'll see:
+
+    42 FXS        FXOKS      (In use)
+
+
+
+Asterisk Level Information
+~~~~~~~~~~~~~~~~~~~~~~~~~~
   asterisk -rx 'zap show channels'
 
-  - If you get error "Unable to connect to remote asterisk" then it
-    means that the Asterisk is not running. It is possible that Asterisk
-    has failed to start due to misconfigured zapata.conf or whatever reason.
-    Check /var/log/asterisk/messages or /var/log/asterisk/full .
-  - If you get the error that "there is no such command" then it means that
-    chan_zap.so is not loaded. There are two reasons for such problem:
-    (a) chan_zap.so is not even built. Check if the file exists:
-
-         ls -l /usr/lib/asterisk/modules/chan_zap.so
-
-    (b) the chan_zap.so file exists but it is not loaded. Try to load it manually:
-
-         asterisk -rx 'load module chan_zap.so'
-
-  - You see "pseudo" channel only. It means that you have not configured any
-    channels. If you have configured channels in zapata.conf, you may
-    need either to restart the Asterisk or unload/load chan_zap.so manually.
-    You can use the following Asterisk CLI commands for it: `unload chan_zap.so` and 
-    `load chan_zap.so`
+- If you get error "Unable to connect to remote asterisk" then it
+  means that the Asterisk is not running. It is possible that Asterisk
+  has failed to start due to misconfigured zapata.conf or whatever reason.
+  Check /var/log/asterisk/messages or /var/log/asterisk/full .
+- If you get the error that "there is no such command" then it means that
+  chan_zap.so is not loaded. There are two reasons for such problem:
+  * chan_zap.so is not even built. Check if the file exists:
+
+       ls -l /usr/lib/asterisk/modules/chan_zap.so
+
+  * the chan_zap.so file exists but it is not loaded. Try to load it manually:
+
+       asterisk -rx 'load module chan_zap.so'
+
+- You see "pseudo" channel only. It means that you have not configured any
+  channels. If you have configured channels in zapata.conf, you may
+  need either to restart the Asterisk or unload/load chan_zap.so manually.
+  You can use the following Asterisk CLI commands for it: `unload chan_zap.so` 
+  and `load chan_zap.so`
+
+
+Known Issues
+~~~~~~~~~~~~
+Empty /proc dir
+^^^^^^^^^^^^^^^
+.Symptoms:
+- Error message:
+
+  "ERR-xpd_fxo: XBUS-00/XPD-00: Failed initializing registers (-22)"
+  
+- Likewise for all XPDs. 
+- The directory /proc/xpp exists but is empty (not even the files 
+  'xbuses' and 'sync').
+
+.Cause:
+The driver failed to recreate the procfs directory /proc/xpp and hence
+everything under it. This is because it has already existed. And it
+existed because a process still uses it. This is typically because you
+have a shell whose working directory is /proc/xpp or somewhere under
+it:
+
+  # lsof /proc/xpp
+  COMMAND  PID USER   FD   TYPE DEVICE SIZE       NODE NAME
+  bash    2741 root  cwd    DIR    0,3    0 4026532684 /proc/xpp
+
+.Fix:
+Move that process from that directory, or close the file it uses from
+under /proc/xpp and reload the zaptel / xpp drivers.
+
+
+Bad Firmware Version
+^^^^^^^^^^^^^^^^^^^^
+.Symptoms:
+- An Astribank finishes initialization quickly, the /proc/XBUS-nn
+  directory has no XPD-mm subdirectories.
+- Error in the kernel logs about:
+
+  NOTICE-xpp: XBUS-00: XPD at 00: type=6.0 has bad firmware revision 2.6 
+
+.Cause:
+This is normally caused by an Astribank with an older firmware connected
+to a 
+
+The protocol version supported by the firmware will typically be the same 
+one as in the device initialization scripts installed to 
+/usr/share/zaptel . Hence if this version installed 
+`/usr/share/zaptel/init_card_3_29` it will probably include firmware of 
+protocol version 29.
+
+.Fix:
+Reset the firmware:
+
+  /usr/share/zaptel/xpp_fxloader reset
+
+Or disconnect the Astribank and reocnnect. On some older versions of the
+USB firmware resetting the firmware (or any operation of fpga_load)
+would fail if the driver is loaded. Hence you would need to run 
+`rmmod xpp_usb` . In the end, reload the drivers.
+
+
+USB Errors at Shutdown
+^^^^^^^^^^^^^^^^^^^^^^
+.Symptoms:
+You see USB-related errors similar to the following whenever you shut
+down the drivers of the Astribank or disconnect its drivers:
+
+  ERR-xpp_usb: XBUS-00: Failed to submit a receive urb
+
+.Cause:
+This is a normal part of the shutdown of the USB connection. 
+
+.Fix:
+Ignore them. Unless the USB should not have disconnected at that time.
 
 
 Reference
@@ -756,6 +845,7 @@
 Now to the ugly details:
 
 The driver of the Astribank is composed of several modules: 
+
 * xpp     - the basic module, that communicates with Zaptel and provides
             some common services to other modules.
 * xpd_fxs - the module for controlling FXS modules.
@@ -782,9 +872,10 @@
 When command 'modprobe xpp_usb' returns, the span type specific modules
 (e.g., xpd_fxs, xpd_fxo) may or may not have been loaded yet.
 
-At this point the xpp driver "asks" the box about type of telephony modules
-it has. According to the answers it receives, the xpp driver will "modprobe"
-the required xpd_* modules. 
+At this point the xpp driver "asks" the box about its software
+(firmware) version) and the type of telephony modules it has. According 
+to the answers it receives, the xpp driver will "modprobe" the required 
+xpd_* modules. 
 
 
 Device Initializations Scripts
@@ -799,6 +890,9 @@
 * N  - is 3 for an FXS span and 4 for an FXO span, and 6 or 7 for BRI.
 * MM - is a version number. Currently it equals 26
 
+Those scripts must be executable. Funny things happen if such a script
+exists but is not executable.
+
 If because of some reasons this fails (the script is not in the place, or the
 file doesn't have the executable permissions), then you will get an error 
 message in the logs and the XPD will then be removed (you won't see directory
@@ -809,20 +903,6 @@
 turn on and later off ("a train of lights"). This is a bit slower than the 
 faster "blinking" when the XPDs register as Zaptel spans. The initializaton 
 of an FXS XPD may take a few seconds.
-
-
-Astribank in Sysfs
-^^^^^^^^^^^^^^^^^^
-When an Astribank device loads it generates a device node in the bus 
-'astribanks' in sysfs. You can see a directory for each device under 
-/sys/bus/astribanks/devices/ and under it there are several attributes
-for each Astribank (such as its connector string).
-
-On each time an Astribank is initialized or destroyed a udev event is
-generated. The rules from our sample udev rules file (xpp/utils/xpp.rules) 
-make that event run the script /usr/share/zaptel/astribank_hook with the
-parameter 'add' or 'remove', if such script exists. An example script
-that just adjusts the Astribank sync settings is included in xpp/utils. 
 
 
 Registering in Zaptel
@@ -894,8 +974,13 @@
 /proc Interface
 ~~~~~~~~~~~~~~~
 The Astribank drivers provide their own /proc interface under /proc/xpp.
-(Note that the details of this interface are still potentially subject to 
-changes)
+Here we review the more useful details of the procfs interface. There
+are many other debugging details that are exposed through the debugfs
+interface. 
+
+Also note that those details are subject to changes. Generally the
+recommended stable interface are the zaptel-perl utilities from the
+xpp/utils directory.
 
 
 /proc/xpp/xbuses
@@ -931,6 +1016,17 @@
 module (span in the therms of Zaptel) there is folder /proc/XBUS-nn/XPD-mm.
 
 
+/proc/xpp/XBUS-nn/waitfor_xpds
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Reading from this file only returns when the Astribank has finished
+initialization of the XPDs or in case of a timeout. It prints the number
+of XPDs to initialize, and the number initialize. Unless something went
+wrong, those two numbers are the same. Once the span was initialized,
+reading from this file returns immediately:
+
+  XPDS_READY: XBUS-00: 3/3
+
+
 /proc/xpp/XBUS-nn/XPD-mm/zt_registration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 is a read/write file. Reading from it gives 0 if the span is
@@ -1042,6 +1138,39 @@
 configuration file] .
 
 There are a bunch of other status files under /proc/xpp/.
+
+
+/sys Interface
+~~~~~~~~~~~~~~~
+When an Astribank device loads it generates a device node in the bus 
+'astribanks' in sysfs. You can see a directory for each device under 
+/sys/bus/astribanks/devices/ and under it there are several attributes
+for each Astribank (such as its connector string).
+
+On each time an Astribank is initialized or destroyed a udev event is
+generated. The rules from our sample udev rules file (xpp/utils/xpp.rules) 
+make that event run the script /usr/share/zaptel/astribank_hook with the
+parameter 'add' or 'remove', if such script exists. An example script
+that just adjusts the Astribank sync settings is included in xpp/utils. 
+
+cls::
+  CLear Statistics: writing to this file clear the procfs statistics for
+  this bus.
+
+connector::
+  Connector string for the device. The place to which the Astribank is
+  connected. e.g: usb-0000:00:03.3-2
+
+label::
+  The label string of the Astribank unit. E.g: usb-0000:00:03.3-2
+
+status::
+  'connected' (normal operation) or 'disconnected' (has been disconnected,
+  some channels are still open).
+
+timing::
+  Provides some statistics in case the astribank is not the sync source.
+  The format of this file is subject to future changes.
 
 
 Useful Module Parameters

Modified: team/kpfleming/battery_alarms/kernel/xpp/calibrate_slics
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/calibrate_slics?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/calibrate_slics (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/calibrate_slics Fri Mar  7 09:22:59 2008
@@ -129,7 +129,7 @@
 31	WI	13	00	00
                           
 31	WI	14	F0	7E
-31	WI	15	60	01
+31	WI	15	C0	01
 31	WI	16	00	00
 31	WI	17	00	20
                           

Modified: team/kpfleming/battery_alarms/kernel/xpp/card_bri.c
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/card_bri.c?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/card_bri.c (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/card_bri.c Fri Mar  7 09:22:59 2008
@@ -43,10 +43,6 @@
 DEF_PARM(int, print_dbg, 0, 0644, "Print DBG statements");	/* must be before zap_debug.h */
 DEF_PARM(uint, poll_interval, 500, 0644, "Poll channel state interval in milliseconds (0 - disable)");
 DEF_PARM_BOOL(nt_keepalive, 1, 0644, "Force BRI_NT to keep trying connection");
-#ifdef	DEBUG_PCMTX
-DEF_PARM(int, pcmtx, -1, 0644, "Forced PCM value to transmit (negative to disable)");
-DEF_PARM(int, pcmtx_chan, 0, 0644, "channel to force PCM value");
-#endif
 
 enum xhfc_states {
 	ST_RESET		= 0,	/* G/F0	*/
@@ -499,7 +495,7 @@
 	xbus_log(xbus, xpd, 1, reg_cmd, sizeof(reg_cmd_t));	/* 1 = TX */
 #else
 	if(print_dbg)
-		dump_xframe("SEND_BRI_MULTI", xbus, xframe);
+		dump_xframe("SEND_BRI_MULTI", xbus, xframe, print_dbg);
 #endif
 	ret = send_cmd_frame(xbus, xframe);
 	if(ret < 0)
@@ -685,6 +681,9 @@
 		/* Nothing to do yet */
 		return 0;
 	}
+#ifdef ZT_SPANSTAT_V2 
+	xpd->span.spantype = "BRI";
+#endif 
 	xpd->span.linecompat = ZT_CONFIG_AMI | ZT_CONFIG_CCS;
 	xpd->span.deflaw = ZT_LAW_ALAW;
 	BIT_SET(xpd->digital_signalling, 2);	/* D-Channel */

Modified: team/kpfleming/battery_alarms/kernel/xpp/card_fxo.c
URL: http://svn.digium.com/view/zaptel/team/kpfleming/battery_alarms/kernel/xpp/card_fxo.c?view=diff&rev=3962&r1=3961&r2=3962
==============================================================================
--- team/kpfleming/battery_alarms/kernel/xpp/card_fxo.c (original)
+++ team/kpfleming/battery_alarms/kernel/xpp/card_fxo.c Fri Mar  7 09:22:59 2008
@@ -40,6 +40,13 @@
 DEF_PARM(uint, poll_metering_interval, 500, 0644, "Poll metering interval in milliseconds (0 - disable)");
 #endif
 DEF_PARM(int, ring_debounce, 50, 0644, "Number of ticks to debounce a false RING indication");
+DEF_PARM(int, caller_id_style, 0, 0444, "Caller-Id detection style: 0 - [BELL], 1 - [BT], 2 - [PASS]");
+
+enum cid_style {
+	CID_STYLE_BELL		= 0,	/* E.g: US (Bellcore) */
+	CID_STYLE_ETSI_POLREV	= 1,	/* E.g: UK (British Telecom) */
+	CID_STYLE_PASS_ALWAYS	= 2,	/* E.g: DK */
+};
 
 /* Signaling is opposite (fxs signalling for fxo card) */
 #if 1
@@ -55,9 +62,18 @@
 #define	NUM_LEDS		1
 #define	DELAY_UNTIL_DIALTONE	3000
 
-#define	POLREV_THRESHOLD	1000	/* minimum duration for polarity reversal detection (in ticks) */
+/*
+ * Minimum duration for polarity reversal detection (in ticks)
+ * Should be longer than the time to detect a ring, so voltage
+ * fluctuation during ring won't trigger false detection.
+ */
+#define	POLREV_THRESHOLD	200
 #define	BAT_THRESHOLD		3
 #define	BAT_DEBOUNCE		1000	/* compensate for battery voltage fluctuation (in ticks) */
+#define	POWER_DENIAL_CURRENT	3
+#define	POWER_DENIAL_TIME	80	/* ticks */
+#define	POWER_DENIAL_SAFEZONE	100	/* ticks */
+#define	POWER_DENIAL_DELAY	2500	/* ticks */
 
 /* Shortcuts */
 #define	DAA_WRITE	1
@@ -82,6 +98,7 @@
 static int proc_xpd_register_read(char *page, char **start, off_t off, int count, int *eof, void *data);
 static int proc_xpd_register_write(struct file *file, const char __user *buffer, unsigned long count, void *data);
 static int handle_register_command(xpd_t *xpd, char *cmdline);
+static void zap_report_battery(xpd_t *xpd, lineno_t chan);
 
 #define	PROC_REGISTER_FNAME	"slics"
 #define	PROC_FXO_INFO_FNAME	"fxo_info"
@@ -94,8 +111,17 @@
 #define	DAA_REG_CURRENT		0x1C	/* 28 */
 #define	DAA_REG_VBAT		0x1D	/* 29 */
 
-#define	POWER_DENIAL_CURRENT	3
-#define	POWER_DENIAL_TIME	80	/* ticks */
+enum battery_state {
+	BATTERY_UNKNOWN	= 0,
+	BATTERY_ON		= 1,
+	BATTERY_OFF		= -1
+};
+
+enum polarity_state {
+	POL_UNKNOWN	= 0,
+	POL_POSITIVE	= 1,
+	POL_NEGATIVE	= -1
+};
 
 struct FXO_priv_data {
 	struct proc_dir_entry	*regfile;
@@ -105,11 +131,15 @@
 	struct proc_dir_entry	*fxo_info;
 	uint			poll_counter;
 	signed char		battery_voltage[CHANNELS_PERXPD];
-	xpp_line_t		battery;
-	ushort			battery_debounce[CHANNELS_PERXPD];
-	xpp_line_t		polarity;
-	ushort			polarity_counter[CHANNELS_PERXPD];
-	ushort			current_counter[CHANNELS_PERXPD];
+	signed char		battery_current[CHANNELS_PERXPD];
+	enum battery_state	battery[CHANNELS_PERXPD];
+	ushort			nobattery_debounce[CHANNELS_PERXPD];
+	enum polarity_state	polarity[CHANNELS_PERXPD];
+	ushort			polarity_debounce[CHANNELS_PERXPD];
+	xpp_line_t		maybe_power_denial;
+	ushort			power_denial_debounce[CHANNELS_PERXPD];
+	ushort			power_denial_delay[CHANNELS_PERXPD];
+	ushort			power_denial_safezone[CHANNELS_PERXPD];
 	xpp_line_t		ledstate[NUM_LEDS];	/* 0 - OFF, 1 - ON */
 	xpp_line_t		ledcontrol[NUM_LEDS];	/* 0 - OFF, 1 - ON */
 	int			led_counter[NUM_LEDS][CHANNELS_PERXPD];
@@ -133,6 +163,16 @@
 #define	LED_BLINK_RING			(1000/8)	/* in ticks */
 
 /*---------------- FXO: Static functions ----------------------------------*/
+
+static void reset_battery_readings(xpd_t *xpd, lineno_t pos)
+{
+	struct FXO_priv_data	*priv = xpd->priv;
+
+	priv->nobattery_debounce[pos] = 0;
+	priv->power_denial_debounce[pos] = 0;
+	priv->power_denial_delay[pos] = 0;
+	BIT_CLR(priv->maybe_power_denial, pos);
+}
 
 /*
  * LED control is done via DAA register 0x20
@@ -208,10 +248,16 @@
 
 	BUG_ON(!xpd);
 	if(on) {
-		BIT_CLR(xpd->cid_on, pos);
+		if(caller_id_style == CID_STYLE_BELL) {
+			LINE_DBG(SIGNAL, xpd, pos, "Caller-ID PCM: off\n");
+			BIT_CLR(xpd->cid_on, pos);
+		}
 		rxsig = ZT_RXSIG_RING;
 	} else {
-		BIT_SET(xpd->cid_on, pos);
+		if(caller_id_style == CID_STYLE_BELL) {
+			LINE_DBG(SIGNAL, xpd, pos, "Caller-ID PCM: on\n");
+			BIT_SET(xpd->cid_on, pos);
+		}
 		rxsig = ZT_RXSIG_OFFHOOK;
 	}
 	pcm_recompute(xpd, 0);
@@ -235,7 +281,7 @@
 	 * We don't want to check battery during ringing
 	 * due to voltage fluctuations.
 	 */
-	priv->battery_debounce[pos] = 0;
+	reset_battery_readings(xpd, pos);
 	if(on && !xpd->ringing[pos]) {
 		LINE_DBG(SIGNAL, xpd, pos, "START\n");
 		xpd->ringing[pos] = 1;
@@ -265,8 +311,9 @@
 	xbus = xpd->xbus;
 	priv = xpd->priv;
 	BUG_ON(!priv);
-	if(!IS_SET(priv->battery, pos)) {
-		LINE_DBG(SIGNAL, xpd, pos, "WARNING: called while battery is off\n");
+	if(priv->battery[pos] != BATTERY_ON && to_offhook) {
+		LINE_NOTICE(xpd, pos, "Cannot take offhook while battery is off!\n");
+		return -EINVAL;
 	}
 	spin_lock_irqsave(&xpd->lock, flags);
 	mark_ring(xpd, pos, 0, 0);				// No more rings
@@ -281,6 +328,9 @@
 		BIT_SET(xpd->offhook, pos);
 	} else {
 		BIT_CLR(xpd->offhook, pos);
+	}
+	if(caller_id_style != CID_STYLE_PASS_ALWAYS) {
+		LINE_DBG(SIGNAL, xpd, pos, "Caller-ID PCM: off\n");
 		BIT_CLR(xpd->cid_on, pos);
 	}
 #ifdef	WITH_METERING
@@ -288,6 +338,8 @@
 	priv->metering_tone_state = 0L;
 	DAA_DIRECT_REQUEST(xbus, xpd, pos, DAA_WRITE, DAA_REG_METERING, 0x2D);
 #endif
+	reset_battery_readings(xpd, pos);	/* unstable during hook changes */
+	priv->power_denial_safezone[pos] = (to_offhook) ? POWER_DENIAL_SAFEZONE : 0;
 	spin_unlock_irqrestore(&xpd->lock, flags);
 	return ret;
 }
@@ -387,6 +439,8 @@
 	// Hanghup all lines
 	for_each_line(xpd, i) {
 		do_sethook(xpd, i, 0);
+		priv->polarity[i] = POL_UNKNOWN;	/* will be updated on next battery sample */
+		priv->battery[i] = BATTERY_UNKNOWN;	/* will be updated on next battery sample */
 	}
 	XPD_DBG(GENERAL, xpd, "done\n");
 	for_each_line(xpd, i) {
@@ -431,6 +485,9 @@
 	priv = xpd->priv;
 	BUG_ON(!priv);
 	XPD_DBG(GENERAL, xpd, "%s\n", (on)?"ON":"OFF");
+#ifdef ZT_SPANSTAT_V2 
+	xpd->span.spantype = "FXO";
+#endif 
 	for_each_line(xpd, i) {
 		struct zt_chan	*cur_chan = &xpd->chans[i];
 
@@ -461,6 +518,7 @@
 	BUG_ON(!priv);
 	XPD_DBG(GENERAL, xpd, "%s\n", (on)?"ON":"OFF");
 	for_each_line(xpd, i) {
+		zap_report_battery(xpd, i);
 		MARK_OFF(priv, i, LED_GREEN);
 		msleep(2);
 		// MARK_OFF(priv, i, LED_RED);
@@ -472,6 +530,7 @@
 static int FXO_card_hooksig(xbus_t *xbus, xpd_t *xpd, int pos, zt_txsig_t txsig)
 {
 	struct FXO_priv_data	*priv;
+	int			ret = 0;
 
 	priv = xpd->priv;
 	BUG_ON(!priv);
@@ -482,10 +541,10 @@
 		case ZT_TXSIG_START:
 			break;
 		case ZT_TXSIG_OFFHOOK:
-			do_sethook(xpd, pos, 1);
+			ret = do_sethook(xpd, pos, 1);
 			break;
 		case ZT_TXSIG_ONHOOK:
-			do_sethook(xpd, pos, 0);
+			ret = do_sethook(xpd, pos, 0);
 			break;
 		default:
 			XPD_NOTICE(xpd, "Can't set tx state to %s (%d)\n",
@@ -493,7 +552,30 @@
 			return -EINVAL;
 	}
 	pcm_recompute(xpd, 0);
-	return 0;
+	return ret;
+}
+
+static void zap_report_battery(xpd_t *xpd, lineno_t chan)
+{
+	struct FXO_priv_data	*priv;
+
+	BUG_ON(!xpd);
+	priv = xpd->priv;
+	if(SPAN_REGISTERED(xpd)) {
+		switch(priv->battery[chan]) {
+			case BATTERY_UNKNOWN:
+				/* no-op */
+				break;
+			case BATTERY_OFF:
+				LINE_DBG(SIGNAL, xpd, chan, "Send ZT_ALARM_RED\n");
+				zt_alarm_channel(&xpd->chans[chan], ZT_ALARM_RED);
+				break;
+			case BATTERY_ON:
+				LINE_DBG(SIGNAL, xpd, chan, "Send ZT_ALARM_NONE\n");
+				zt_alarm_channel(&xpd->chans[chan], ZT_ALARM_NONE);
+				break;
+		}
+	}
 }
 
 static int FXO_card_open(xpd_t *xpd, lineno_t chan)
@@ -502,14 +584,6 @@
 
 	BUG_ON(!xpd);
 	priv = xpd->priv;
-	/*
-	 * We pretend to have battery. If this is really the case
-	 * than next calls to update_battery_status() won't change it.
-	 * If we don't have battery, than on the next calls to
-	 * update_battery_status() a battery_debounce[] cycle would start.
-	 * Than, if no-battery is persistent, asterisk would be notified.
-	 */
-	BIT_SET(priv->battery, chan);
 	return 0;
 }
 
@@ -563,6 +637,37 @@
 	}
 }
 
+static void handle_fxo_power_denial(xpd_t *xpd)
+{
+	struct FXO_priv_data	*priv;
+	int			i;
+
+	priv = xpd->priv;
+	for_each_line(xpd, i) {
+		if(priv->power_denial_safezone[i] > 0)
+			priv->power_denial_safezone[i]--;
+		if(IS_SET(priv->maybe_power_denial, i) && !xpd->ringing[i] && IS_SET(xpd->offhook, i)) {
+			/*
+			 * Ring detection by the firmware takes some time.
+			 * Therefore we delay our decision until we are
+			 * sure that no ring has started during this time.
+			 */
+			priv->power_denial_delay[i]++;
+			if (priv->power_denial_delay[i] >= POWER_DENIAL_DELAY) {
+				LINE_DBG(SIGNAL, xpd, i, "Power Denial Hangup\n");
+				priv->power_denial_delay[i] = 0;
+				BIT_CLR(priv->maybe_power_denial, i);
+				do_sethook(xpd, i, 0);
+				update_line_status(xpd, i, 0);
+				pcm_recompute(xpd, 0);
+			}
+		} else {
+			priv->power_denial_delay[i] = 0;
+			BIT_CLR(priv->maybe_power_denial, i);
+		}
+	}
+}
+
 static int FXO_card_tick(xbus_t *xbus, xpd_t *xpd)
 {
 	struct FXO_priv_data	*priv;
@@ -580,6 +685,7 @@
 #endif
 	handle_fxo_leds(xpd);
 	handle_fxo_ring(xpd);
+	handle_fxo_power_denial(xpd);
 	priv->poll_counter++;
 	return 0;
 }
@@ -686,10 +792,13 @@
 		int	debounce;
 
 		if(IS_SET(sig_toggles, i)) {
-			if(!IS_SET(priv->battery, i)) {
-				LINE_DBG(SIGNAL, xpd, i, "SIG_CHANGED while battery is off.\n");
-				// FIXME: allow dialing without battery polling...
-				// continue;
+			if(priv->battery[i] == BATTERY_OFF) {
+				/*
+				 * With poll_battery_interval==0 we cannot have BATTERY_OFF
+				 * so we won't get here
+				 */
+				LINE_NOTICE(xpd, i, "SIG_CHANGED while battery is off. Ignored.\n");
+				continue;
 			}
 			/* First report false ring alarms */
 			debounce = atomic_read(&priv->ring_debounce[i]);
@@ -711,103 +820,152 @@
 #define zt_alarm_channel(a,b) zt_qevent_lock(a,( (b)==ZT_ALARM_NONE )? \
 	ZT_EVENT_NOALARM : ZT_EVENT_ALARM)
 #endif
-static void update_battery_status(xpd_t *xpd, byte data_low, lineno_t chipsel)
-{
-	struct FXO_priv_data	*priv;
-	byte			bat = abs((signed char)data_low);
-	byte			pol = IS_SET(data_low, 7);
+static void update_battery_voltage(xpd_t *xpd, byte data_low, lineno_t chipsel)
+{
+	struct FXO_priv_data	*priv;
+	enum polarity_state	pol;
 	int			msec;
-
 
 	priv = xpd->priv;
 	BUG_ON(!priv);
 	priv->battery_voltage[chipsel] = data_low;
-	if(bat < BAT_THRESHOLD) {
+	if(xpd->ringing[chipsel])
+		goto ignore_reading;	/* ring voltage create false alarms */
+	if(abs((signed char)data_low) < BAT_THRESHOLD) {
 		/*
 		 * Check for battery voltage fluctuations
 		 */
-		if(IS_SET(priv->battery, chipsel)) {
+		if(priv->battery[chipsel] != BATTERY_OFF) {
 			int	milliseconds;
 
-			milliseconds = priv->battery_debounce[chipsel]++ *
+			milliseconds = priv->nobattery_debounce[chipsel]++ *
 				poll_battery_interval;
 			if(milliseconds > BAT_DEBOUNCE) {
-				LINE_DBG(SIGNAL, xpd, chipsel, "BATTERY OFF voltage=%d\n", bat);
-				BIT_CLR(priv->battery, chipsel);
+				LINE_DBG(SIGNAL, xpd, chipsel, "BATTERY OFF voltage=%d\n", data_low);
+				priv->battery[chipsel] = BATTERY_OFF;
 				if(SPAN_REGISTERED(xpd))
-					zt_alarm_channel(&xpd->chans[chipsel], ZT_ALARM_RED);
+					zap_report_battery(xpd, chipsel);
+				priv->polarity[chipsel] = POL_UNKNOWN;	/* What's the polarity ? */
+				/*
+				 * Stop further processing for now
+				 */
+				goto ignore_reading;
 			}
 
 		}
 	} else {
-		priv->battery_debounce[chipsel] = 0;
-		if(!IS_SET(priv->battery, chipsel)) {
-			LINE_DBG(SIGNAL, xpd, chipsel, "BATTERY ON voltage=%d\n", bat);
-			BIT_SET(priv->battery, chipsel);
+		priv->nobattery_debounce[chipsel] = 0;
+		if(priv->battery[chipsel] != BATTERY_ON) {
+			LINE_DBG(SIGNAL, xpd, chipsel, "BATTERY ON voltage=%d\n", data_low);
+			priv->battery[chipsel] = BATTERY_ON;
 			if(SPAN_REGISTERED(xpd))
-				zt_alarm_channel(&xpd->chans[chipsel], ZT_ALARM_NONE);
+				zap_report_battery(xpd, chipsel);
 		}
+	}
+	if(priv->battery[chipsel] != BATTERY_ON) {
+		priv->polarity[chipsel] = POL_UNKNOWN;	/* What's the polarity ? */
+		return;
 	}
 	/*
 	 * Handle reverse polarity
 	 */
-	if(IS_SET(priv->polarity, chipsel) == pol) {
-		/* same, same, nothing to see here, move on */
-		priv->polarity_counter[chipsel] = 0;
+	if(data_low == 0)
+		pol = POL_UNKNOWN;
+	else if(IS_SET(data_low, 7))
+		pol = POL_NEGATIVE;
+	else
+		pol = POL_POSITIVE;
+	if(priv->polarity[chipsel] == pol) {
+		/*
+		 * Same polarity, reset debounce counter
+		 */

[... 6922 lines stripped ...]



More information about the zaptel-commits mailing list