[dahdi-commits] tzafrir: linux/trunk r4418 - /linux/trunk/drivers/dahdi/xpp/

SVN commits to the DAHDI project dahdi-commits at lists.digium.com
Thu Jun 19 13:13:12 CDT 2008


Author: tzafrir
Date: Thu Jun 19 13:13:11 2008
New Revision: 4418

URL: http://svn.digium.com/view/dahdi?view=rev&rev=4418
Log:
Yet another zaptel->dahdi rename. XPP file names this time.

Added:
    linux/trunk/drivers/dahdi/xpp/dahdi_debug.c
      - copied, changed from r4403, linux/trunk/drivers/dahdi/xpp/zap_debug.c
    linux/trunk/drivers/dahdi/xpp/dahdi_debug.h
      - copied, changed from r4403, linux/trunk/drivers/dahdi/xpp/zap_debug.h
    linux/trunk/drivers/dahdi/xpp/xpp_dahdi.c
      - copied, changed from r4403, linux/trunk/drivers/dahdi/xpp/xpp_zap.c
    linux/trunk/drivers/dahdi/xpp/xpp_dahdi.h
      - copied, changed from r4403, linux/trunk/drivers/dahdi/xpp/xpp_zap.h
Removed:
    linux/trunk/drivers/dahdi/xpp/xpp_zap.c
    linux/trunk/drivers/dahdi/xpp/xpp_zap.h
    linux/trunk/drivers/dahdi/xpp/zap_debug.c
    linux/trunk/drivers/dahdi/xpp/zap_debug.h
Modified:
    linux/trunk/drivers/dahdi/xpp/Kbuild
    linux/trunk/drivers/dahdi/xpp/README.Astribank
    linux/trunk/drivers/dahdi/xpp/card_bri.c
    linux/trunk/drivers/dahdi/xpp/card_fxo.c
    linux/trunk/drivers/dahdi/xpp/card_fxs.c
    linux/trunk/drivers/dahdi/xpp/card_global.c
    linux/trunk/drivers/dahdi/xpp/card_pri.c
    linux/trunk/drivers/dahdi/xpp/mmapdrv.c
    linux/trunk/drivers/dahdi/xpp/xbus-core.c
    linux/trunk/drivers/dahdi/xpp/xbus-pcm.c
    linux/trunk/drivers/dahdi/xpp/xbus-pcm.h
    linux/trunk/drivers/dahdi/xpp/xbus-sysfs.c
    linux/trunk/drivers/dahdi/xpp/xframe_queue.c
    linux/trunk/drivers/dahdi/xpp/xpd.h
    linux/trunk/drivers/dahdi/xpp/xpp.conf
    linux/trunk/drivers/dahdi/xpp/xpp_usb.c
    linux/trunk/drivers/dahdi/xpp/xproto.c
    linux/trunk/drivers/dahdi/xpp/xproto.h

Modified: linux/trunk/drivers/dahdi/xpp/Kbuild
URL: http://svn.digium.com/view/dahdi/linux/trunk/drivers/dahdi/xpp/Kbuild?view=diff&rev=4418&r1=4417&r2=4418
==============================================================================
--- linux/trunk/drivers/dahdi/xpp/Kbuild (original)
+++ linux/trunk/drivers/dahdi/xpp/Kbuild Thu Jun 19 13:13:11 2008
@@ -25,7 +25,7 @@
 obj-$(DAHDI_BUILD_ALL)$(CONFIG_XPP_MMAP)		+= xpp_mmap.o
 endif
 
-xpp-objs		+= xbus-core.o xbus-sysfs.o xbus-pcm.o xframe_queue.o xpp_zap.o xproto.o card_global.o zap_debug.o
+xpp-objs		+= xbus-core.o xbus-sysfs.o xbus-pcm.o xframe_queue.o xpp_dahdi.o xproto.o card_global.o dahdi_debug.o
 xpd_fxs-objs		+= card_fxs.o
 xpd_fxo-objs		+= card_fxo.o
 xpd_bri-objs		+= card_bri.o

Modified: linux/trunk/drivers/dahdi/xpp/README.Astribank
URL: http://svn.digium.com/view/dahdi/linux/trunk/drivers/dahdi/xpp/README.Astribank?view=diff&rev=4418&r1=4417&r2=4418
==============================================================================
--- linux/trunk/drivers/dahdi/xpp/README.Astribank (original)
+++ linux/trunk/drivers/dahdi/xpp/README.Astribank Thu Jun 19 13:13:11 2008
@@ -3,7 +3,7 @@
 Xorcom Team <support at xorcom.com>
 $Revision$, $Date$
 
-This file documents the Zaptel drivers for the Xorcom Channel Bank.
+This file documents the Dahdi drivers for the Xorcom Channel Bank.
 The drivers reside in a separate subdirectory, kernel/xpp/ .
 
 It is generally a more technical document than the 
@@ -15,34 +15,26 @@
 Building and Installation
 -------------------------
 Building and installation is basically like the normal procedure of 
-installing Zaptel with some additions.
+installing Dahdi with some additions.
 
 Building drivers
 ~~~~~~~~~~~~~~~~
-Apart from the standard Zaptel build requirements, you also need libusb
+Apart from the standard Dahdi build requirements, you also need libusb
 development headers to build the fpga_load firmware loader. This is
 typically the package libusb-dev on Debian (and derivatives like Ubuntu)
 or libusb-devel on RedHat (and derivatives like CentOS/Trixbox).
 
-On Zaptel 1.2 you will need to run the following extra step to build the
-user space utilities, apart from the standard 'make; make install':
-
-  make -C xpp/utils install
-
-Though this should be done automatically on Zaptel >= 1.4.1 .
-
-
 Sample Configurations
 ---------------------
 We generally recommend to generate the configuration by using utility
-genzaptelconf or zapconf which are included with Zaptel. Nevertheless,
+genzaptelconf or zapconf which are included with Dahdi. Nevertheless,
 the following can serve as reference configurations for a system where 
 Astribank devices are used.
 
 
-Zaptel Init Configuration File
+Dahdi Init Configuration File
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The zaptel init.d script, genzaptelconf and the XPD init scripts uses the 
+The dahdi init.d script, genzaptelconf and the XPD init scripts uses the 
 parameters located in file /etc/default/zaptel (on Debian) or 
 /etc/sysconfig/zaptel (on RedHats). There is a number of useful parameters 
 that may be defined there:
@@ -60,14 +52,14 @@
 
 # Equivalent to the parameter opermode to the module wctdm: country-specific
 # settings to the FXO lines. For a complete list of possible values, see
-# /usr/share/zaptel/init_fxo_mode .
+# /usr/share/dahdi/init_fxo_mode .
 #opermode=FRANCE
 
 # xpp_sync runs with the value of 'XPP_SYNC' as its parameter to set the
 # synchronization source. The default is 'auto' that selects the best
-# Astribank. 'ZAPTEL' gets synchronization from the Zaptel sync master
+# Astribank. 'DAHDI' gets synchronization from the Dahdi sync master
 # span. Or a specific XBUS number.
-#XPP_SYNC=ZAPTEL
+#XPP_SYNC=DAHDI
 
 # Disables hot-plug firmware loading
 #XPP_HOTPLUG_DISABLED=yes
@@ -87,7 +79,7 @@
 #	'
 -----------------------------------------------------------
 
-/etc/zaptel.conf
+/etc/dahdi.conf
 ~~~~~~~~~~~~~~~~
 
 Astribank 8
@@ -307,7 +299,7 @@
 
 -----------------------------------------------------------
 [phones-zap]
-; 6001 will dial to channel 1, 6020, to Zaptel channel 20, etc.
+; 6001 will dial to channel 1, 6020, to Dahdi channel 20, etc.
 exten => _6XXX,1,Dial(ZAP/${EXTEN:1})
 ; Useful for debugging trunks. Will potentially allow users to
 ; bypass context limitations.
@@ -335,7 +327,7 @@
 [from-pstn] 
 ; Calls from the PSTN enter here. Redirect calls to an IVR 
 ; or a default extension in the s context here. In this case we  
-; redirect calls to Zaptel channel 1: 
+; redirect calls to Dahdi channel 1: 
 exten => s,1,Dial(Zap/1) 
 
 ; Alternatively, the following will redirect you to the demo IVR 
@@ -364,7 +356,7 @@
 ; configuration below. 
 ;exten => s,n,Set(INPUT_NUM=$[${ZAP_CHAN}-11)]) 
 ; The sample below just logs the signal.  
-exten => s,n,NoOp(Got signal from Zaptel Channel ${ZAP_CHAN}) 
+exten => s,n,NoOp(Got signal from Dahdi Channel ${ZAP_CHAN}) 
 ; Alternatively: 
 ;exten => s,n,System(run something) 
 
@@ -385,14 +377,14 @@
 ~~~~~~~~~~
 Check USB level status. You can use one of the following utilities for it:
 
-  zaptel_hardware -v
+  dahdi_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
+  dahdi_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
@@ -401,46 +393,46 @@
   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
+  building Dahdi. 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
+Dahdi Registration
 ~~~~~~~~~~~~~~~~~~~
-Check if the Astribank spans are registered in Zaptel
-
-  zt_registration
+Check if the Astribank spans are registered in Dahdi
+
+  dahdi_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
+  the span has not been registered in Dahdi and therefore can not be used
   yet.
-- Registration is normally done as part of `/etc/init.d/zaptel start`.
+- Registration is normally done as part of `/etc/init.d/dahdi start`.
   If you want to register the spans manually, then run command:
-  `zt_registration on` .
+  `dahdi_registration on` .
 - Disabling of the automatic Astribank spans registration give you full
-  control on the order of Zaptel spans. See the module parameter
+  control on the order of Dahdi spans. See the module parameter
   **zap_autoreg** for the further details.
 
 
-Zaptel Level Information
+Dahdi Level Information
 ~~~~~~~~~~~~~~~~~~~~~~~~
-You can get some information regarding Zaptel channels by running one of the
+You can get some information regarding Dahdi channels by running one of the
 following commands:
 
-    lszaptel
+    lsdahdi
        or
-    cat /proc/zaptel/*
-
-- Those two are almost the same. The lszaptel produced more correctly sorted
+    cat /proc/dahdi/*
+
+- Those two are almost the same. The lsdahdi 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
+- You can see if your Dahdi spans and channels were loaded, if
   they were configured by ztcfg and if they are in use (typically by
   Asterisk).
   For example:
@@ -449,7 +441,7 @@
      42 FXS
 
 - When a channel has been configured with *ztcfg* (that applies
-  /etc/zaptel.conf), you will see an extra column for the signalling
+  /etc/dahdi.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
@@ -511,7 +503,7 @@
 
 .Fix:
 Move that process from that directory, or close the file it uses from
-under /proc/xpp and reload the zaptel / xpp drivers.
+under /proc/xpp and reload the dahdi / xpp drivers.
 
 
 Bad Firmware Version
@@ -529,14 +521,14 @@
 
 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 
+/usr/share/dahdi . Hence if this version installed 
+`/usr/share/dahdi/init_card_3_29` it will probably include firmware of 
 protocol version 29.
 
 .Fix:
 Reset the firmware:
 
-  /usr/share/zaptel/xpp_fxloader reset
+  /usr/share/dahdi/xpp_fxloader reset
 
 Or disconnect the Astribank from the power and reocnnect. On some older 
 versions of the USB firmware resetting the firmware (or any operation of 
@@ -565,7 +557,7 @@
 With the BRI module only, and not in the middle of an active call, you
 notice that suddenly the line goes down. The LED of the port stops
 blinking, layer1 not listed as "active" in the bri_info file in
-/proc/xpp, and the span is in RED alarm in Zaptel.
+/proc/xpp, and the span is in RED alarm in Dahdi.
 
 You may also see an error message such as:
 
@@ -609,7 +601,7 @@
 The problem is what to do if both of those exist. Selecting an arbitrary
 one can lead to unexpected results. Likewise sourcing both of them.
 Therefore we prefer to fail in a noisy and expected way. In the future
-we will probably me to reading configuration from a file under /etc/zaptel .
+we will probably me to reading configuration from a file under /etc/dahdi .
 
 .Fix:
 Remove one of those two. There should be no reason to have both on the
@@ -639,7 +631,7 @@
 .Fix:
 Reset the firmware of the Astribank by either:
 
-  /usr/share/zaptel/xpp_fxloader reset
+  /usr/share/dahdi/xpp_fxloader reset
 
 or disconnecting it from the power and reconnecting it.
 
@@ -697,17 +689,17 @@
 behavior:
 
 Each port in the PRI module can be configured either as E1 or T1. The
-port type defaults to E1 and can be changed to T1 in the Zaptel Init 
+port type defaults to E1 and can be changed to T1 in the Dahdi Init 
 Configuration File.
 
 The Astribank xpp driver uses that information for correct hardware
-initialization that is performed before the Zaptel span registration
+initialization that is performed before the Dahdi span registration
 process takes place. Because of that, xpp driver can't use the 
-information from file zaptel.conf.
-
-Another parameter that also can be defined in the Zaptel Init
+information from file dahdi.conf.
+
+Another parameter that also can be defined in the Dahdi Init
 Configuration File is the function group TE (CPE) or NT (Network). This
-parameter is used for (a) building correct Zaptel & Asterisk
+parameter is used for (a) building correct Dahdi & Asterisk
 configuration by genzaptelconf and (b) control RJ-45 sockets LEDs for 
 better visual port control:
 
@@ -724,7 +716,7 @@
 
 To set them to a non-default value, you should use the variable
 XPP_PRI_SETUP in the 
-xref:_zaptel_init_configuration_file[Zaptel Init Configuration File]
+xref:dahdi_init_configuration_file[Dahdi Init Configuration File]
 (/etc/sysconfig/zaptel on Redhats, /etc/default/zaptel on Debians).
 This value is a whitespace-separated list of conditions. When a port is 
 initialized it checks those conditions and uses the first one that 
@@ -790,18 +782,18 @@
 ~~~~~~~~~~~~~~
 This section describes in great depth the initialization of the Xorcom
 Astribank. Normally it would not be really needed, as the standard
-installation of Zaptel should put everything in place.
+installation of Dahdi should put everything in place.
 
 Terminology
 ^^^^^^^^^^^
 There are some technical terms that are used in this document and in the
-driver / zaptel.
+driver / dahdi.
 
 span:
-Zaptel breaks the channels it knows about to logical units called
+Dahdi breaks the channels it knows about to logical units called
 "spans". A port in a E1/T1/ISDN card is usually a span. An whole
 analog card is also a "span". You can see the list of spans as the list
-of files under /proc/zaptel directory or in output of the zttool
+of files under /proc/dahdi directory or in output of the zttool
 utility.
 
 XBUS:
@@ -809,13 +801,13 @@
 
 XPD:
 Basically this is a logical unit of the Astribank. It will be registered in
-Zaptel as a single span. This can be either an analog (FXS or FXO)
+Dahdi as a single span. This can be either an analog (FXS or FXO)
 module or a single port in case of a BRI module.
 
 
 Loading Firmware
 ^^^^^^^^^^^^^^^^
-Normally this is done using the script /usr/share/zaptel/xpp_fxloader.
+Normally this is done using the script /usr/share/dahdi/xpp_fxloader.
 If it works fine, you don't need to bother reading this section.
 Once the firmware is loaded the USB Vendor ID and Product ID of the Astribank
 became to be e4e4 11x2, and now the driver can pick it up.
@@ -825,8 +817,8 @@
 if its firmware is loaded. 
 
 The firmware files are named *.hex. They are presented in the text
-hexadecimal format The files are copied from xpp/utils to /usr/share/zaptel
-folder during the Zaptel installation.
+hexadecimal format The files are copied from xpp/utils to /usr/share/dahdi
+folder during the Dahdi installation.
 
 The Astribank needs a firmware loaded into it. Without the firmware, 
 the device will appear in lsusb with Vendor ID e4e4 and Product ID 1130.
@@ -837,7 +829,7 @@
 You can use the following command in order to load the "USB" firmware
 manually:
 
-  fxload -t fx2 -D /proc/bus/usb/MMM/NNN -I /usr/share/zaptel/USB_FW.hex
+  fxload -t fx2 -D /proc/bus/usb/MMM/NNN -I /usr/share/dahdi/USB_FW.hex
 
 where,
 
@@ -858,12 +850,12 @@
 In the second stage, the "FPGA" firmware is loaded.
 The second-stage firmware loading is performed by using program fpga_load, 
 which is built in the directory xpp/utils and then copied to folder 
-/usr/sbin during Zaptel installation.
+/usr/sbin during Dahdi installation.
 
 The command syntax is similar to the syntax of fxload. You can use the 
 following command in order to load the FPGA firmware manually:
 
-  fpga_load -D /proc/bus/usb/MMM/NNN -I /usr/share/zaptel/FPGA_1151.hex
+  fpga_load -D /proc/bus/usb/MMM/NNN -I /usr/share/dahdi/FPGA_1151.hex
 
 Please note, that  NNN value differs from that that was used for the 
 fxload command due to the fact that device has "reconnected" itself 
@@ -911,7 +903,7 @@
 In order to get udev to automatically load the firmware into the Astribank, 
 the configuration file xpp.rules should be copied into folder /etc/udev/rules.d 
 and the script xpp_fxloader should be copied into folder /etc/hotplug/usb/ . 
-This is done by 'make -C xpp/utils install' during Zaptel installation.
+This is done by 'make -C xpp/utils install' during Dahdi installation.
 
 File xpp.rules instructs the udevd daemon to run xpp_fxloader script with
 the option "udev" and with the Astribank USB ID obtained from the 
@@ -927,11 +919,11 @@
 
 Also you can try the following:
 
-  /usr/share/zaptel/xpp_fxloader reset
+  /usr/share/dahdi/xpp_fxloader reset
   # if asterisk was running: you may need to stop/restart it now. 
   # if there are some "disconnected" spans in /proc/xpp/xbuses
   # wait a while, until you see the 1152 IDs again, and then:
-  /etc/init.d/zaptel start
+  /etc/init.d/dahdi start
   # and start/restart asterisk.
 
 
@@ -953,7 +945,7 @@
 
 The driver of the Astribank is composed of several modules: 
 
-* xpp     - the basic module, that communicates with Zaptel and provides
+* xpp     - the basic module, that communicates with Dahdi and provides
             some common services to other modules.
 * xpd_fxs - the module for controlling FXS modules.
 * xpd_fxo - the module for controlling FXO modules. 
@@ -971,7 +963,7 @@
 combination is listed as the kernel module xpp_usb. Therefore, the system
 runs 'modprobe xpp_usb' if that module is not already loaded.
 
-The module xpp_usb depends on the zaptel and xpp modules. Both of them 
+The module xpp_usb depends on the dahdi and xpp modules. Both of them 
 are loaded before xpp_usb. As usual, parameters and rules form
 /etc/modprobe.conf and/or from /etc/modprobe.d/* will be applied to 
 the module.
@@ -990,8 +982,8 @@
 The chips in the device need to be initialized. This requires sending a
 bunch of values to certain registers in those chips. We decided that
 hardwiring those values in the driver code is not a good idea.
-Before registering a XPD as a span in Zaptel, we run an initialization
-script: /usr/share/zaptel/init_card_N_MM (
+Before registering a XPD as a span in Dahdi, we run an initialization
+script: /usr/share/dahdi/init_card_N_MM (
 where,
 
 * N  - is 3 for an FXS span and 4 for an FXO span, and 6 or 7 for BRI.
@@ -1004,75 +996,75 @@
 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
 for that XPD under the corresponding /proc/xpp/XBUS-* directory) and will not
-be registered in Zaptel.
+be registered in Dahdi.
 
 As the XPD is initialized, you'll see the green LEDs of the ports steadily 
 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 initialization 
+faster "blinking" when the XPDs register as Dahdi spans. The initialization 
 of an FXS XPD may take a few seconds.
 
 
-Registering in Zaptel
+Registering in Dahdi
 ^^^^^^^^^^^^^^^^^^^^^
-The XPDs will not automatically register as Zaptel spans. This is
+The XPDs will not automatically register as Dahdi spans. This is
 intended to allow you to set the registration order (and hence the order
-of Zaptel spans and channels) among multiple Astribank devices,
-or between an Astribank and a different Zaptel device.
-
-When the XPD registers to Zaptel, all the green LEDs will be lit for a
+of Dahdi spans and channels) among multiple Astribank devices,
+or between an Astribank and a different Dahdi device.
+
+When the XPD registers to Dahdi, all the green LEDs will be lit for a
 short while. 
 
-Spans are normally registered with the utility zt_registration. Simply
-running 'zt_registration' shows the available XPDs and whether or not
+Spans are normally registered with the utility dahdi_registration. Simply
+running 'dahdi_registration' shows the available XPDs and whether or not
 they are registered. To register: 
 
-  zt_registration on
+  dahdi_registration on
 
 For a system with several spans you'll see a "fast train of lights".
 
-If you have multiple Astribank devices, zt_registration will register
+If you have multiple Astribank devices, dahdi_registration will register
 them by the order of the "connector" field. This means that as long as
 the same Astribank is connected to the same port, the order of plugging
 is not important..
 
-zt_registration checks if a span is registered or tries to register a
-span using the file /proc/xpp/XBUS-nn/XPD-mm/zt_registration . Reading
+dahdi_registration checks if a span is registered or tries to register a
+span using the file /proc/xpp/XBUS-nn/XPD-mm/dahdi_registration . Reading
 from that file returns 0 if the span is unregisters or 1 if it is
 registered. You can register a span or ask to unregister it by writing 1
 (register) or 0 (unregister) to that file. Registration should
 generally always succeed. Unregistration may fail if a span is in use.
 
-You may choose to register the XPDs in Zaptel automatically. This may
+You may choose to register the XPDs in Dahdi automatically. This may
 make the startup sequence a bit simpler, but is generally not
 recommended on a system with more than one Astribank or an Astribank and
-a different Zaptel device. This behavior may be defined by setting 
+a different Dahdi device. This behavior may be defined by setting 
 parameter zap_autoreg in the modprobe configuration file (A file under 
 /etc/modprobe.d or /etc/modprobe.conf):
 
   options xpp zap_autoreg=1
 
 
-Zaptel And Above
+Dahdi And Above
 ^^^^^^^^^^^^^^^^
-From here you get a standard Zaptel span. It still needs to be
+From here you get a standard Dahdi span. It still needs to be
 configured by ztcfg and used by a program such as Asterisk like any
-other Zaptel device. In order for you to get a dial-tone in a phone
+other Dahdi device. In order for you to get a dial-tone in a phone
 connected to the FXS port or a fully synchronized BRI port (layer 2
 activated, as signalled by a more steady blink) you will actually need
-both the span configured by Zaptel and the channels configured in
+both the span configured by Dahdi and the channels configured in
 Asterisk.
 
-You should generally refer to the general Zaptel documentation on how to
+You should generally refer to the general Dahdi documentation on how to
 configure those levels. e.g, the README file in the top-level directory,
 and
 
   http://voip-info.org/wiki/view/Asterisk+config+zapata.conf[]
 
 
-Zaptel now includes a utility called genzaptelconf (written as a big
-ugly shell script) to configure Zaptel automatically as good as
+Dahdi now includes a utility called genzaptelconf (written as a big
+ugly shell script) to configure Dahdi automatically as good as
 possible. For analog channels it works quite well (because, IMHO, the
-"configuration" level on Zaptel should be optional there - there are
+"configuration" level on Dahdi should be optional there - there are
 already sane defaults). For digital spans - BRI and PRI , it may take
 some tuning.
 
@@ -1088,7 +1080,7 @@
 interface. 
 
 Also note that those details are subject to changes. Generally the
-recommended stable interface are the Zaptel-perl utilities from the
+recommended stable interface are the Dahdi-perl utilities from the
 xpp/utils directory.
 
 
@@ -1114,15 +1106,15 @@
 <number>::
   Make the Astribank XBUS-<number> the sync source for other Astribanks.
 
-ZAPTEL::
-  Make the Astribanks synchronize with the Zaptel timing master span.
+DAHDI::
+  Make the Astribanks synchronize with the Dahdi timing master span.
   You probably need this to get faxes from a non-Astribank adapter to an
   Astribank.
 
 Though you'll normally use xpp_sync(8) for that.
 
 For each Astribank device there is folder /proc/xpp/XBUS-nn and for each device
-module (span in the terms of Zaptel) there is folder /proc/XBUS-nn/XPD-mm.
+module (span in the terms of Dahdi) there is folder /proc/XBUS-nn/XPD-mm.
 
 
 /proc/xpp/XBUS-nn/waitfor_xpds
@@ -1136,23 +1128,23 @@
   XPDS_READY: XBUS-00: 3/3
 
 
-/proc/xpp/XBUS-nn/XPD-mm/zt_registration
+/proc/xpp/XBUS-nn/XPD-mm/dahdi_registration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 is a read/write file. Reading from it gives 0 if the span is
 unregistered, or the span number if it is registered.
 
-Writing to it allows manual registration / unregistration from Zaptel:
+Writing to it allows manual registration / unregistration from Dahdi:
 writing 1 registers a span (if it wasn't already registered) and writing
 0 attempts to unregister it (if it is registered.  Span unregistration 
 will fail if some channels from the span are used  (e.g: by Asterisk).
 
-A more convenient interface to this is the command zt_registration that
+A more convenient interface to this is the command dahdi_registration that
 registers or unregisters all the spans at once with a predefined order,
 and this is what you should normally use.
 
 Alternatively you can use the parameter zap_autoreg to register spans
 automatically. But this is only recommended on a system with a single
-Astribank and no other Zaptel device.
+Astribank and no other Dahdi device.
 
 
 /proc/xpp/XBUS-nn/XPD-mm/summary 
@@ -1216,7 +1208,7 @@
 
 Writing to this file can be used to change the type of the device. The
 device type can only be changed when the XPD is not registered as a
-Zaptel span. The value is a whitespace-separated list of values that can 
+Dahdi span. The value is a whitespace-separated list of values that can 
 be of:
 
 E1::
@@ -1248,7 +1240,7 @@
 
 Normally those are set by the PRI initialization script . See the
 definition of XPP_PRI_SETUP in 
-xref:_zaptel_init_configuration_file[the sample Zaptel init 
+xref:dahdi_init_configuration_file[the sample Dahdi init 
 configuration file] .
 
 
@@ -1264,7 +1256,7 @@
 
 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
+make that event run the script /usr/share/dahdi/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. 
 
@@ -1296,13 +1288,13 @@
 zap_autoreg (xpp)::
   Register spans automatically (1) or not (0). Default: 0. 
   Setting it simplifies operations with a single Astribank and no other 
-  Zaptel hardware. However if you have such systems, automatic
+  Dahdi hardware. However if you have such systems, automatic
   registration can cause the order of spans to be unpredictable.
-  The standard startup scripts use 'zt_registration on' instead of this.
+  The standard startup scripts use 'dahdi_registration on' instead of this.
 
 initdir (xpp)::
   This is the directory containing the initialization scripts.
-  The default is /usr/share/zaptel .
+  The default is /usr/share/dahdi .
   Setting this value could be useful if that location is inconvenient for you.
 
 rx_tasklet (xpp)::
@@ -1322,7 +1314,7 @@
   * 4  - LEDS - Anything related to the LEDs status control. The driver
          produces a lot of messages when the option is enabled.
   * 8  - SYNC - Synchronization related messages.
-  * 16 - SIGNAL - Zaptel signalling related messages.
+  * 16 - SIGNAL - Dahdi signalling related messages.
   * 32 - PROC - Messages related to the procfs interface.
   * 64 - REGS - Reading and writing to chip registers. Tends to flood
   	 logs.

Modified: linux/trunk/drivers/dahdi/xpp/card_bri.c
URL: http://svn.digium.com/view/dahdi/linux/trunk/drivers/dahdi/xpp/card_bri.c?view=diff&rev=4418&r1=4417&r2=4418
==============================================================================
--- linux/trunk/drivers/dahdi/xpp/card_bri.c (original)
+++ linux/trunk/drivers/dahdi/xpp/card_bri.c Thu Jun 19 13:13:11 2008
@@ -28,9 +28,9 @@
 #include <linux/delay.h>
 #include "xpd.h"
 #include "xproto.h"
-#include "xpp_zap.h"
+#include "xpp_dahdi.h"
 #include "card_bri.h"
-#include "zap_debug.h"
+#include "dahdi_debug.h"
 #include "xbus-core.h"
 
 static const char rcsid[] = "$Id$";
@@ -39,7 +39,7 @@
 #error CONFIG_ZAPATA_BRI_DCHANS is not defined
 #endif
 
-static DEF_PARM(int, debug, 0, 0644, "Print DBG statements");	/* must be before zap_debug.h */
+static DEF_PARM(int, debug, 0, 0644, "Print DBG statements");	/* must be before dahdi_debug.h */
 static DEF_PARM(uint, poll_interval, 500, 0644, "Poll channel state interval in milliseconds (0 - disable)");
 static DEF_PARM_BOOL(nt_keepalive, 1, 0644, "Force BRI_NT to keep trying connection");
 
@@ -505,7 +505,7 @@
 	if(debug)
 		dump_dchan_packet(xpd, 0, dchan_buf, idx /* - 3 */);	/* Print checksum? */
 	/* 
-	 * Tell Zaptel that we received idx-1 bytes. They include the data and a 2-byte checksum.
+	 * Tell Dahdi that we received idx-1 bytes. They include the data and a 2-byte checksum.
 	 * The last byte (that we don't pass on) is 0 if the checksum is correct. If it were wrong,
 	 * we would drop the packet in the "if(dchan_buf[idx-1])" above.
 	 */
@@ -655,7 +655,7 @@
 	return 0;
 }
 
-static int BRI_card_zaptel_preregistration(xpd_t *xpd, bool on)
+static int BRI_card_dahdi_preregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct BRI_priv_data	*priv;
@@ -737,7 +737,7 @@
 	return 0;
 }
 
-static int BRI_card_zaptel_postregistration(xpd_t *xpd, bool on)
+static int BRI_card_dahdi_postregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct BRI_priv_data	*priv;
@@ -956,7 +956,7 @@
 }
 
 /*
- * Called only for 'span' keyword in /etc/zaptel.conf
+ * Called only for 'span' keyword in /etc/dahdi.conf
  */
 static int bri_spanconfig(struct dahdi_span *span, struct dahdi_lineconfig *lc)
 {
@@ -999,8 +999,8 @@
 
 /*
  * Set signalling type (if appropriate)
- * Called from zaptel with spinlock held on chan. Must not call back
- * zaptel functions.
+ * Called from dahdi with spinlock held on chan. Must not call back
+ * dahdi functions.
  */
 static int bri_chanconfig(struct dahdi_chan *chan, int sigtype)
 {
@@ -1012,7 +1012,7 @@
 }
 
 /*
- * Called only for 'span' keyword in /etc/zaptel.conf
+ * Called only for 'span' keyword in /etc/dahdi.conf
  */
 static int bri_startup(struct dahdi_span *span)
 {
@@ -1024,7 +1024,7 @@
 	priv = xpd->priv;
 	BUG_ON(!priv);
 	if(!TRANSPORT_RUNNING(xpd->xbus)) {
-		XPD_DBG(GENERAL, xpd, "Startup called by zaptel. No Hardware. Ignored\n");
+		XPD_DBG(GENERAL, xpd, "Startup called by dahdi. No Hardware. Ignored\n");
 		return -ENODEV;
 	}
 	XPD_DBG(GENERAL, xpd, "STARTUP\n");
@@ -1034,10 +1034,10 @@
 		dchan = &span->chans[2];
 		span->flags |= DAHDI_FLAG_RUNNING;
 		/*
-		 * Zaptel (wrongly) assume that D-Channel need HDLC decoding
-		 * and during zaptel registration override our flags.
+		 * Dahdi (wrongly) assume that D-Channel need HDLC decoding
+		 * and during dahdi registration override our flags.
 		 *
-		 * Don't Get Mad, Get Even:  Now we override zaptel :-)
+		 * Don't Get Mad, Get Even:  Now we override dahdi :-)
 		 */
 		dchan->flags |= DAHDI_FLAG_BRIDCHAN;
 		dchan->flags &= ~DAHDI_FLAG_HDLC;
@@ -1046,7 +1046,7 @@
 }
 
 /*
- * Called only for 'span' keyword in /etc/zaptel.conf
+ * Called only for 'span' keyword in /etc/dahdi.conf
  */
 static int bri_shutdown(struct dahdi_span *span)
 {
@@ -1057,7 +1057,7 @@
 	priv = xpd->priv;
 	BUG_ON(!priv);
 	if(!TRANSPORT_RUNNING(xpd->xbus)) {
-		XPD_DBG(GENERAL, xpd, "Shutdown called by zaptel. No Hardware. Ignored\n");
+		XPD_DBG(GENERAL, xpd, "Shutdown called by dahdi. No Hardware. Ignored\n");
 		return -ENODEV;
 	}
 	XPD_DBG(GENERAL, xpd, "SHUTDOWN\n");
@@ -1391,8 +1391,8 @@
 		.card_new	= BRI_card_new,
 		.card_init	= BRI_card_init,
 		.card_remove	= BRI_card_remove,
-		.card_zaptel_preregistration	= BRI_card_zaptel_preregistration,
-		.card_zaptel_postregistration	= BRI_card_zaptel_postregistration,
+		.card_dahdi_preregistration	= BRI_card_dahdi_preregistration,
+		.card_dahdi_postregistration	= BRI_card_dahdi_postregistration,
 		.card_hooksig	= BRI_card_hooksig,
 		.card_tick	= BRI_card_tick,
 		.card_pcm_fromspan	= BRI_card_pcm_fromspan,

Modified: linux/trunk/drivers/dahdi/xpp/card_fxo.c
URL: http://svn.digium.com/view/dahdi/linux/trunk/drivers/dahdi/xpp/card_fxo.c?view=diff&rev=4418&r1=4417&r2=4418
==============================================================================
--- linux/trunk/drivers/dahdi/xpp/card_fxo.c (original)
+++ linux/trunk/drivers/dahdi/xpp/card_fxo.c Thu Jun 19 13:13:11 2008
@@ -26,9 +26,9 @@
 #include <linux/delay.h>
 #include "xpd.h"
 #include "xproto.h"
-#include "xpp_zap.h"
+#include "xpp_dahdi.h"
 #include "card_fxo.h"
-#include "zap_debug.h"
+#include "dahdi_debug.h"
 #include "xbus-core.h"
 
 static const char rcsid[] = "$Id$";
@@ -97,7 +97,7 @@
 #ifdef	WITH_METERING
 static int proc_xpd_metering_read(char *page, char **start, off_t off, int count, int *eof, void *data);
 #endif
-static void zap_report_battery(xpd_t *xpd, lineno_t chan);
+static void dahdi_report_battery(xpd_t *xpd, lineno_t chan);
 
 #define	PROC_REGISTER_FNAME	"slics"
 #define	PROC_FXO_INFO_FNAME	"fxo_info"
@@ -261,7 +261,7 @@
 	spin_unlock_irqrestore(&xpd->lock, flags);
 }
 
-static void update_zap_ring(xpd_t *xpd, int pos, bool on)
+static void update_dahdi_ring(xpd_t *xpd, int pos, bool on)
 {
 	dahdi_rxsig_t	rxsig;
 
@@ -289,7 +289,7 @@
 		dahdi_hooksig(&xpd->chans[pos], rxsig);
 }
 
-static void mark_ring(xpd_t *xpd, lineno_t pos, bool on, bool update_zap)
+static void mark_ring(xpd_t *xpd, lineno_t pos, bool on, bool update_dahdi)
 {
 	struct FXO_priv_data	*priv;
 
@@ -305,15 +305,15 @@
 		LINE_DBG(SIGNAL, xpd, pos, "START\n");
 		xpd->ringing[pos] = 1;
 		MARK_BLINK(priv, pos, LED_GREEN, LED_BLINK_RING);
-		if(update_zap)
-			update_zap_ring(xpd, pos, on);
+		if(update_dahdi)
+			update_dahdi_ring(xpd, pos, on);
 	} else if(!on && xpd->ringing[pos]) {
 		LINE_DBG(SIGNAL, xpd, pos, "STOP\n");
 		xpd->ringing[pos] = 0;
 		if(IS_BLINKING(priv, pos, LED_GREEN))
 			MARK_BLINK(priv, pos, LED_GREEN, 0);
-		if(update_zap)
-			update_zap_ring(xpd, pos, on);
+		if(update_dahdi)
+			update_dahdi_ring(xpd, pos, on);
 	}
 }
 
@@ -494,7 +494,7 @@
 	return 0;
 }
 
-static int FXO_card_zaptel_preregistration(xpd_t *xpd, bool on)
+static int FXO_card_dahdi_preregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct FXO_priv_data	*priv;
@@ -527,7 +527,7 @@
 	return 0;
 }
 
-static int FXO_card_zaptel_postregistration(xpd_t *xpd, bool on)
+static int FXO_card_dahdi_postregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct FXO_priv_data	*priv;
@@ -540,7 +540,7 @@
 	BUG_ON(!priv);
 	XPD_DBG(GENERAL, xpd, "%s\n", (on)?"ON":"OFF");
 	for_each_line(xpd, i) {
-		zap_report_battery(xpd, i);
+		dahdi_report_battery(xpd, i);
 		MARK_OFF(priv, i, LED_GREEN);
 		msleep(2);
 		MARK_OFF(priv, i, LED_RED);
@@ -577,7 +577,7 @@
 	return ret;
 }
 
-static void zap_report_battery(xpd_t *xpd, lineno_t chan)
+static void dahdi_report_battery(xpd_t *xpd, lineno_t chan)
 {
 	struct FXO_priv_data	*priv;
 
@@ -856,7 +856,7 @@
 				LINE_DBG(SIGNAL, xpd, portno, "BATTERY OFF voltage=%d\n", data_low);
 				priv->battery[portno] = BATTERY_OFF;
 				if(SPAN_REGISTERED(xpd))
-					zap_report_battery(xpd, portno);
+					dahdi_report_battery(xpd, portno);
 				priv->polarity[portno] = POL_UNKNOWN;	/* What's the polarity ? */
 				priv->power[portno] = POWER_UNKNOWN;	/* What's the current ? */
 				/*
@@ -872,7 +872,7 @@
 			LINE_DBG(SIGNAL, xpd, portno, "BATTERY ON voltage=%d\n", data_low);
 			priv->battery[portno] = BATTERY_ON;
 			if(SPAN_REGISTERED(xpd))
-				zap_report_battery(xpd, portno);
+				dahdi_report_battery(xpd, portno);
 		}
 	}
 #if 0
@@ -923,7 +923,7 @@
 			LINE_DBG(SIGNAL, xpd, portno,
 				"Polarity changed to %s\n", polname);
 			/*
-			 * Inform zaptel/Asterisk:
+			 * Inform dahdi/Asterisk:
 			 * 1. Maybe used for hangup detection during offhook
 			 * 2. In some countries used to report caller-id during onhook
 			 *    but before first ring.
@@ -1066,8 +1066,8 @@
 		.card_new	= FXO_card_new,
 		.card_init	= FXO_card_init,
 		.card_remove	= FXO_card_remove,
-		.card_zaptel_preregistration	= FXO_card_zaptel_preregistration,
-		.card_zaptel_postregistration	= FXO_card_zaptel_postregistration,
+		.card_dahdi_preregistration	= FXO_card_dahdi_preregistration,
+		.card_dahdi_postregistration	= FXO_card_dahdi_postregistration,
 		.card_hooksig	= FXO_card_hooksig,
 		.card_tick	= FXO_card_tick,
 		.card_pcm_fromspan	= generic_card_pcm_fromspan,

Modified: linux/trunk/drivers/dahdi/xpp/card_fxs.c
URL: http://svn.digium.com/view/dahdi/linux/trunk/drivers/dahdi/xpp/card_fxs.c?view=diff&rev=4418&r1=4417&r2=4418
==============================================================================
--- linux/trunk/drivers/dahdi/xpp/card_fxs.c (original)
+++ linux/trunk/drivers/dahdi/xpp/card_fxs.c Thu Jun 19 13:13:11 2008
@@ -26,14 +26,14 @@
 #include <linux/delay.h>
 #include "xpd.h"
 #include "xproto.h"
-#include "xpp_zap.h"
+#include "xpp_dahdi.h"
 #include "card_fxo.h"
-#include "zap_debug.h"
+#include "dahdi_debug.h"
 #include "xbus-core.h"
 
 static const char rcsid[] = "$Id$";
 
-static DEF_PARM(int, debug, 0, 0644, "Print DBG statements");	/* must be before zap_debug.h */
+static DEF_PARM(int, debug, 0, 0644, "Print DBG statements");	/* must be before dahdi_debug.h */
 static DEF_PARM_BOOL(reversepolarity, 0, 0644, "Reverse Line Polarity");
 static DEF_PARM_BOOL(vmwineon, 0, 0644, "Indicate voicemail to a neon lamp");
 static DEF_PARM_BOOL(dtmf_detection, 1, 0644, "Do DTMF detection in hardware");
@@ -130,8 +130,8 @@
 	xpp_line_t		search_fsk_pattern;
 	xpp_line_t		found_fsk_pattern;
 	xpp_line_t		update_offhook_state;
-	xpp_line_t		want_dtmf_events;	/* what zaptel want */
-	xpp_line_t		want_dtmf_mute;		/* what zaptel want */
+	xpp_line_t		want_dtmf_events;	/* what dahdi want */
+	xpp_line_t		want_dtmf_mute;		/* what dahdi want */
 	int			led_counter[NUM_LEDS][CHANNELS_PERXPD];
 	int			ohttimer[CHANNELS_PERXPD];
 #define OHT_TIMER		6000	/* How long after RING to retain OHT */
@@ -465,7 +465,7 @@
 	return 0;
 }
 
-static int FXS_card_zaptel_preregistration(xpd_t *xpd, bool on)
+static int FXS_card_dahdi_preregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct FXS_priv_data	*priv;
@@ -506,7 +506,7 @@
 	return 0;
 }
 
-static int FXS_card_zaptel_postregistration(xpd_t *xpd, bool on)
+static int FXS_card_dahdi_postregistration(xpd_t *xpd, bool on)
 {
 	xbus_t			*xbus;
 	struct FXS_priv_data	*priv;
@@ -894,9 +894,9 @@
 	else
 		LINE_DBG(SIGNAL, xpd, chan, "is onhook\n");
 	/*
-	 * Delegate updating zaptel to FXS_card_tick():
+	 * Delegate updating dahdi to FXS_card_tick():
 	 *   The problem is that dahdi_hooksig() is spinlocking the channel and
-	 *   we are called by zaptel with the spinlock already held on the
+	 *   we are called by dahdi with the spinlock already held on the
 	 *   same channel.
 	 */
 	BIT_SET(priv->update_offhook_state, chan);
@@ -1065,7 +1065,7 @@
 			if(!IS_SET(priv->update_offhook_state, i))
 				continue;
 			/*
-			 * Update zaptel with current state of line.

[... 1015 lines stripped ...]



More information about the dahdi-commits mailing list