[svn-commits] sruffell: tag linux/2.6.0-rc1 r10313 - /linux/tags/2.6.0-rc1/
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Wed Nov 2 16:59:06 CDT 2011
Author: sruffell
Date: Wed Nov 2 16:59:02 2011
New Revision: 10313
URL: http://svnview.digium.com/svn/dahdi?view=rev&rev=10313
Log:
Importing files for 2.6.0-rc1 release.
Added:
linux/tags/2.6.0-rc1/.version (with props)
linux/tags/2.6.0-rc1/ChangeLog (with props)
Added: linux/tags/2.6.0-rc1/.version
URL: http://svnview.digium.com/svn/dahdi/linux/tags/2.6.0-rc1/.version?view=auto&rev=10313
==============================================================================
--- linux/tags/2.6.0-rc1/.version (added)
+++ linux/tags/2.6.0-rc1/.version Wed Nov 2 16:59:02 2011
@@ -1,0 +1,1 @@
+2.6.0-rc1
Propchange: linux/tags/2.6.0-rc1/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: linux/tags/2.6.0-rc1/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: linux/tags/2.6.0-rc1/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: linux/tags/2.6.0-rc1/ChangeLog
URL: http://svnview.digium.com/svn/dahdi/linux/tags/2.6.0-rc1/ChangeLog?view=auto&rev=10313
==============================================================================
--- linux/tags/2.6.0-rc1/ChangeLog (added)
+++ linux/tags/2.6.0-rc1/ChangeLog Wed Nov 2 16:59:02 2011
@@ -1,0 +1,5794 @@
+2011-11-02 Shaun Ruffell <sruffell at digium.com>
+
+ * dahdi-linux 2.6.0-rc1 released.
+
+2011-11-02 21:46 +0000 [r10310] Russ Meyerriecks <rmeyerreicks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: minor: Removed unnecessary
+ instrumentation Removed a couple prints of instrumentation that
+ was cluttering up the log output. Signed-off-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com> Acked-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+2011-11-02 19:46 +0000 [r10303-10304] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: First span registered becomes
+ master by default. r10205 "dahdi: Check for master in
+ DAHDI_STARTUP / resolves MeetMe regression." did not handle the
+ case for the wcb4xxp driver since it would set DAHDI_FLAG_RUNNING
+ as part of the probe. Therefore, the DAHDI_STARTUP ioctl was
+ never processed for it, creating a situation where audio is
+ missing on channels that are conferenced with channels on the BRI
+ spans. Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * include/dahdi/kernel.h: dahdi: Define POLLRDHUP on kernels <
+ 2.6.17 Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+2011-11-02 17:05 +0000 [r10299-10302] Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c, drivers/dahdi/xpp/card_pri.c,
+ drivers/dahdi/xpp/card_bri.c, drivers/dahdi/xpp/xpp_dahdi.h: xpp:
+ bugfix: clear NOTOPEN span alarm on assign The NOTOPEN span alarm
+ flag is set at span unassignment time. * It needs to be cleared
+ when the span is reassigned. * That is: only if the span is
+ actually connected. Signed-off-by: Tzafrir Cohen
+ <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c: xpp: bugfix -- manage xpd refcount
+ for EC module Signed-off-by: Tzafrir Cohen
+ <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_usb.c, drivers/dahdi/xpp/card_global.c,
+ drivers/dahdi/xpp/xbus-core.h, drivers/dahdi/xpp/init_card_1_30:
+ xpp: Adaptations for E-Main-3 * An xbus transport now have a
+ "model_string" member * The xpp_usb driver fills this with
+ "usb:<idVendor>/<idProduct>/<bcdDevice>" * It is passed via
+ environment to the "init_card_<type>_<protocol>" scripts * The
+ FXS script uses this to condition two registers according to the
+ power supply model. Signed-off-by: Tzafrir Cohen
+ <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/card_fxo.h, drivers/dahdi/xpp/card_fxs.h: xpp:
+ remove leftovers of old XPD_STATE method Signed-off-by: Tzafrir
+ Cohen <tzafrir.cohen at xorcom.com>
+
+2011-11-01 20:35 +0000 [r10290-10296] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/voicebus/GpakCust.c: wctdm24xxp, wcte12xp: Allow
+ VPMADT032 commands more time to complete. Since "wctdm24xxp:
+ Probe for and configure modules in parallel." the check for the
+ VPMADT032 module was moved closer to after when the interface was
+ initialized. The 200ms timeout did not provide enough time for
+ the system to settle out after initial start. The result was that
+ sometimes after a cold boot the driver would fail to detect any
+ VPMADT032 modules. This fixes a race condition that is not in any
+ released branches. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/firmware/Makefile: wctdm24xxp, wcte12xp: Update
+ VPMOCT032 firmware to 1.12.0. - Cleaned up the OCT6114 interface
+ . - Relaxed the timeout waiting for OCT6114 bus cycle completion
+ to 100 mS and added a 2 mS delay time from OCT6114 reset to
+ initialization. This change only addresses issues that were
+ created in the lab and not in the field. Signed-off-by: Doug
+ Bailey <dbailey at digium.com> Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Expose serial number in
+ dahdi_device and kernel log. This will allow the serial number to
+ be exposed in sysfs and also allow span assignment rules to use
+ the serial number. Signed-off-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com> Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/firmware/Makefile, drivers/dahdi/wct4xxp/base.c:
+ wct4xxp: Add field upgradable firmware support for TE820. This
+ commit adds field upgradeable support for the TE820 firmware.
+ Firmware can now be silently upgraded as part of updating drivers
+ like most of the existing DAHDI firmware. Previous versions of
+ dual and quad span cards did not support upgrading firmware in
+ the field. Signed-off-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com> Fixed up some checkpatch issues:
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wct4xxp/wct4xxp.h, drivers/dahdi/firmware/Makefile,
+ drivers/dahdi/wct4xxp/vpm450m.c, drivers/dahdi/wct4xxp/Kbuild,
+ drivers/dahdi/wct4xxp/base.c,
+ drivers/dahdi/oct612x/include/oct6100api/oct6100_defines.h,
+ README: wct4xxp: Add support for TE820 and VPMOCT256. TE820 is an
+ 8-span PCI-express digital interface card. VPMOCT256 is a
+ hardware echo canceler that is able to provide echo cancelation
+ on all 8-spans. From: Matthew Fredrickson <creslin at digium.com>
+ Signed-off-by: Russ Meyerriecks <rmeyerriecks at digium.com>
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+2011-10-27 19:59 +0000 [r10270-10289] Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * README: README: Minor additions regarding pinned-spans
+ Signed-off-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * README: README: initial update for span assignments
+ Signed-off-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c, drivers/dahdi/xpp/xbus-core.c:
+ xpp: cleanup some printk()'s * Also demote them to DBG()
+ Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+
+ * drivers/dahdi/dahdi-sysfs.c: added 'basechan' and 'channels'
+ attributes to spans * So we can: - Generate 'pinned-spans.conf'
+ from existing state - Run dahdi_cfg from udev (on specific span +
+ its channels) Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: Give userspace a chance to
+ respond to surprise removal. * We try very hard to help asterisk
+ understand that we unassign spans. * Implement disable_span(): -
+ Set span + channels to DAHDI_ALARM_NOTOPEN - qevent
+ DAHDI_EVENT_REMOVED * Use disable_span(): - in
+ dahdi_unassign_span() and dahdi_unregister_device() - with long
+ msleep() so asterisk has a chance to get the message - Out of the
+ registration_mutex so we actually context switch. * Also return
+ more POLLERR variants (POLLRDHUP is not portable, should be
+ tested). * Also improve printk(), fix rate_limit increment (was
+ missing) Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c, drivers/dahdi/xpp/xpp_dahdi.h,
+ drivers/dahdi/xpp/xbus-core.c: xpp: Remove dahdi_autoreg
+ parameter: * With pinned-spans all spans are registered to dahdi
+ with the device (and assigned later) * So this parameter cannot
+ function anymore * Also remove the (now) empty xpd_post_init()
+ function. Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c: xpp: more informative span
+ description: * Contains the hardware_id and the local span number
+ Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+
+ * drivers/dahdi/xpp/xbus-core.c: xpp: make unregistration safer
+ (idempotent) * Otherwise, a failed unit initialization (e.g: when
+ init_card_?_?? fails) causes a panic Signed-off-by: Oron Peled
+ <oron.peled at xorcom.com>
+
+ * drivers/dahdi/xpp/xbus-sysfs.c: xpp: adapt to 'location'
+ attribute removal: * Reparent astribanks below their USB
+ transport * This way their location can be derived from their
+ hardware hierarchy. * The tradeoff is that once USB hardware is
+ disconnected, there is no sysfs visibility of the astribank
+ object even if it cannot be release yet due to open channels by
+ asterisk * Thus, we'll need to migrate to "surprise removal" of
+ dahdi devices... Signed-off-by: Oron Peled
+ <oron.peled at xorcom.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c, drivers/dahdi/xpp/card_pri.c,
+ drivers/dahdi/xpp/xpp_dahdi.h: xpp: PRI: use DAHDI new
+ set_spantype() method * Implement pri_set_spantype() method *
+ Refactor code from PRI_card_dahdi_preregistration() into a new
+ apply_pri_protocol(). - It is now called from both
+ PRI_card_dahdi_preregistration() and set_pri_proto() - It now
+ also sets span name + description * Remove old
+ pri_protocol_store() method (pri_protocol is now RO) * Added
+ pri_protocol_bystr() method (maybe promote it to DAHDI?)
+ Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Allow linemode (T1/E1/J1)
+ to be changed via sysfs attribute. Allowing the linemode to be
+ configured with sysfs before the spans are assigned opens the
+ eventualy capability for line mode to be configured with the
+ other physical layer settings per card. Currently linemode is set
+ with either physical jumpers or with a module parameter to the
+ wct4xxp driver that is global for all cards. Default behavior is
+ not changed with this commit. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/wcte12xp/base.c: wcte12xp: Allow linemode (T1/E1)
+ to be changed via sysfs attribute. Allowing the linemode to be
+ configured with sysfs before the spans are assigned opens the
+ eventualy capability for line mode to be configured with the
+ other physical layer settings per card. Currently linemode is set
+ with either physical jumpers or with a module parameter to the
+ wcte12xp driver that is global for all cards. Default behavior is
+ not changed with this commit. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * include/dahdi/kernel.h, drivers/dahdi/dahdi-sysfs.c: dahdi: Allow
+ 'spantype' to be changed before span assignement via sysfs. For
+ some boards, the linemode (E1/T1/J1) is software selectable but
+ needs to be configured before the spans were historically
+ registered since the line mode determines the channel count
+ available on the span. This change exports a "spantype" attribute
+ from the dahdi_device that can be used to set E1/T1/J1 before the
+ spans are assigned. When userspace writes to this attribute (in a
+ <span offset>:<span type string> format), and if the board driver
+ has implemented a set_spantype function in it's dahdi_span_ops,
+ then the board driver can optionally change it's mode before
+ registration. Also part of this change is breaking out the raw
+ data structure initialization of the spans / channels via the
+ dahdi_init_device_spans function since the board drivers may need
+ to reallocate channels / spans as part of this callback. For
+ example, changing from T1 to E1 mode will require allocating 7
+ new channels. Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wcfxo.c, drivers/dahdi/wcte12xp/base.c,
+ drivers/dahdi/wcb4xxp/base.c, include/dahdi/kernel.h,
+ drivers/dahdi/wct4xxp/base.c, drivers/dahdi/wcte11xp.c,
+ drivers/dahdi/dahdi-sysfs.c, drivers/dahdi/wct1xxp.c,
+ drivers/dahdi/wctdm.c, drivers/dahdi/wctdm24xxp/base.c,
+ drivers/dahdi/dahdi-base.c: dahdi: Remove dahdi_span.irq and move
+ dahdi_span.irqmisses into dahdi_device. 'irqmisses' is more a
+ function of the device and there are better ways to get to IRQ
+ for a device than storing it in any DAHDI structures.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wcte12xp/base.c, include/dahdi/kernel.h,
+ drivers/dahdi/dahdi-sysfs.c, drivers/dahdi/dahdi.h,
+ drivers/dahdi/xpp/xbus-core.c, drivers/dahdi/dahdi-base.c: dahdi:
+ Expose dahdi devices in sysfs. This exposes dahdi devices in
+ sysfs and also exposes attributes that will allow user space to
+ control the registration order in spans. This facilitates loading
+ drivers out of order yet keeping consistent span/channel
+ numbering, which in turn will eventually allow the blacklist for
+ DAHDI drivers to be removed. The default behavior, controlled
+ with the auto_register module parameter on dahdi is to number the
+ spans / channels in order like is currently done. So this change
+ does not introduce any new behavior by default. * Writing
+ (anything) to this attribute returns the span to its unassigned
+ state * Fix dahdi_chan_unreg() echocan refcount * Add safeguard
+ against duplicate unassignment to _dahdi_unregister_span() *
+ Remove the span from device_node list, only in
+ dahdi_unregister_device() and not in dahdi_unregister_span() *
+ Free allocated span->span_device in span_sysfs_remove() [is it
+ safe?, didn't cause problem so far...] Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com> Signed-off-by: Oron Peled
+ <oron.peled at xorcom.com> Signed-off-by: Tzafrir Cohen
+ <tzafrir.cohen at xorcom.com> dahdi: Add "hardware_id" dahdi_device
+ attribute. - The "hardware_id" does not change with device
+ location (e.g: when a PCI card is moved from one slot to
+ another). - Not all devices have this attribute. It is legal for
+ it to be NULL (that is the default for all low-level drivers that
+ do not set it explicitly). - When "hardware_id" is NULL, the
+ sysfs attribute value is "\n" Signed-off-by: Oron Peled
+ <oron.peled at xorcom.com> Acked-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * include/dahdi/kernel.h, drivers/dahdi/dahdi-sysfs.c,
+ drivers/dahdi/dahdi-base.c: dahdi: Expose spans in sysfs. This
+ change will facilitate creating rules that will allow spans and
+ channels to be accessed by named device files instead of by
+ numbers. Signed-off-by: Oron Peled <oron.peled at xorcom.com>
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/tor2.c, drivers/dahdi/wcfxo.c,
+ drivers/dahdi/wcte12xp/base.c, include/dahdi/kernel.h,
+ drivers/dahdi/pciradio.c, drivers/dahdi/wct4xxp/base.c,
+ drivers/dahdi/xpp/xbus-sysfs.c,
+ drivers/dahdi/voicebus/voicebus.c,
+ drivers/dahdi/wctdm24xxp/base.c,
+ drivers/dahdi/wcte12xp/wcte12xp.h,
+ drivers/dahdi/wcb4xxp/wcb4xxp.h, drivers/dahdi/xpp/xpp_dahdi.c,
+ drivers/dahdi/wcb4xxp/base.c, drivers/dahdi/xpp/xpp_dahdi.h,
+ drivers/dahdi/wcte11xp.c, drivers/dahdi/wctdm24xxp/wctdm24xxp.h,
+ drivers/dahdi/dahdi_dynamic.c, drivers/dahdi/wctdm.c,
+ drivers/dahdi/wct1xxp.c, drivers/dahdi/xpp/xbus-core.c,
+ drivers/dahdi/dahdi-base.c, drivers/dahdi/xpp/xbus-core.h: dahdi:
+ Register devices instead of individual spans. Increasingly, spans
+ are implemented by devices that support more than a single span.
+ Introduce a 'struct dahdi_device' object which explicitly
+ contains multiple spans. This will allow a cleaner representation
+ of spans and devices in sysfs since order of arrival will not
+ determine the layout of the devices. This also gives the core of
+ dahdi a way to know the relationship between spans. This
+ generalizes similar concepts that were previously xpp specific.
+ The conversion of the xpp code was almost entirely done by Oron
+ and Tzafrir. Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+ Signed-off-by: Oron Peled <oron.peled at xorcom.com> Signed-off-by:
+ Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: dahdi_is_analog_span() ->
+ dahdi_is_digital_span() * dahdi-base.c had a reverse
+ is_analog_span() static function -- fixed. Signed-off-by: Oron
+ Peled <oron.peled at xorcom.com> Acked-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: Add error messages in
+ dahdi_ioctl_chanconfig. Provide more context to trouble shoot
+ failures. Signed-off-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+ Acked-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/xpp/xpp_dahdi.c, drivers/dahdi/dahdi-base.c: dahdi:
+ start handling "surprise device removal". This patch contains
+ interim results while trying to make device removal work
+ correctly: * XPP has protections to prevent dahdi unregistration
+ while channels are open -- they are now removed, so we can
+ unregister immediately. * Handle processes in poll_wait(): - Wake
+ them during dahdi_chan_unreg() after the channel is gone
+ (chan->channo = -1 or chan->file->private_data == NULL) - Test in
+ every wait_event_interruptible() that the channel was not gone
+ (chan->file->private_data) - Return correct values (POLLERR |
+ POLLHUP) instead of some errno (would be important in the future
+ if we modify asterisk to respond correctly to this condition. *
+ Other issues: - If unregistered channel is being polled, than
+ call msleep() before returning, to give other processes a chance
+ (normally, asterisk has RT priority) - Call close_channel() from
+ dahdi_chan_unreg() so it releases related tonezone * There is
+ still a horrible race hidden by msleep(20) in dahdi_chan_unreg()
+ force close channels from dahdi_chan_unreg(): * Mark them via
+ DAHDI_FLAGBIT_OPEN * Call low-level driver close() method if
+ available * What about other closing activities? Signed-off-by:
+ Oron Peled <oron.peled at xorcom.com> Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+2011-10-24 22:19 +0000 [r10269] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Deprecate 't1e1override'
+ module parameter in favor of 'default_linemode'. 't1e1override'
+ isn't immediately apparent what it is supposed to do by the name.
+ Instead 'default_linemode' module parameter can be set to "auto",
+ "t1", or "e1" to make it clear. This change was introduced
+ earlier in the wcte12xp driver. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+2011-10-21 19:32 +0000 [r10226-10252] Shaun Ruffell <sruffell at digium.com>
+
+ * include/dahdi/kernel.h, drivers/dahdi/wctc4xxp/base.c: dahdi:
+ Move WARN_ON_ONCE from wctc4xxp driver to include/dahdi/kernel.h
+ I only generally test on RHEL 4 when testing against kernels
+ older than 2.6.18. Apparently OpenSUSE 10.1 runs with 2.6.16 and
+ doesn't have WARN_ON_ONCE backported. I took the patch Richard
+ Miller originally attached to the issue and moved it to
+ include/dahdi/kernel.h so it would be available for all the board
+ drivers in the future. Internal-Issue-ID: DAHLIN-260 Reported-by:
+ Richard Miller Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wcb4xxp/base.c: wcb4xxp: Do not show LASVEGAS2 as
+ echocan name if vpmsupport is set to 0 This fixes an issue where
+ "EC: LASVEGAS2" was displayed in /proc/dahdi/x for a B410P span
+ even though vpmsupport was disabled with the module parameter.
+ Internal-Issue-ID: DAHLIN-247 Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Refactor t4_serial_setup()
+ to remove t4.globalconfig. Allows the globalconfig member to be
+ removed from the struct t4 and not carried around for the life of
+ the card. Also holds the reglock a little longer for all the
+ framer writes but I realize the startup of the wct4xxp based
+ cards does not need to be optimized. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Trivial. Use ARRAY_SIZE in
+ free_wc() and __handle_leds(). Reduces the amount of code to read
+ in the two functions and fixes checkpatch.pl warnings.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Atomically perform some
+ read/modify/write operations There are read/modify/write
+ operations on the framer that were not protected by any locks.
+ While I didn't notice any code paths that would result in
+ simultaneous accesses to these registers, this change will
+ hopefully save someone else some time in the future verifying
+ that the accesses are safe. A side effect is that the reglock is
+ acquired only once for each read/modify/write cycle as opposed to
+ twice previously. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Fix spelling Contains a
+ minor spelling correction. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Change t4_span.spantype to
+ linemode. Since 'linemode' more accurately describes what
+ spantype is specifying. We can also use an enumeration for the
+ linemode to make it explicit that linemode is only set to one of
+ three possible values. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Trivial refactoring in
+ t4_init_one(). Use some convenience pointers to make the function
+ easier to read as opposed to indexing into the arrays.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Add has_e1_span() helper.
+ All those checks for wc->t1e1 span appear to basically be there
+ to determine if there are *any* E1 spans exported by the card. We
+ can make that explicit by wrapping those tests with a
+ has_e1_span() inline function to help with readability.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wcte12xp/base.c: wcte12xp: Deprecate 't1e1override'
+ module parameter in favor of 'default_linemode'. 't1e1override'
+ isn't immediately apparent what it is supposed to do by the name.
+ Instead 'default_linemode' module parameter can be set to "auto",
+ "t1", or "e1" to make it clear. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove redundant 'vpm'
+ from struct t4. Since removal of the VPM400 support the 'vpm'
+ member of struct t4 is now redundant with the 'vpm450m' member.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove vpm400 support. The
+ VPM400 module is no longer supported by the wct4xxp driver. The
+ VPMOCT064 and VPMOCT128 are. Signed-off-by: Russ Meyerreicks
+ <rmeyerriecks at digium.com> Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove unused debugging
+ code Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Turn off the fancy alarm
+ LEDS. Saves about a 1us on average from the interrupt handler on
+ one test system. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Hold a pointer to the
+ devtype directly Eliminates the need to store a copy of the flags
+ and variety from the global devtype. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove unused fields from
+ 'struct t4' and 'struct t4_span' 'memaddr' and 'memlen' is
+ already cached as part of the underlying pci device so the
+ wct4xxp driver does not need to cache it again. 'canary',
+ 'passno', 'master', and 'oct_rw_count' are unused. In t4_span
+ 'irqmisses' was incremented, but never used anywhere, and there
+ is already the irqmisses on the span itself. Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove prefetching
+ support. I was unable to measure a performance change with
+ prefetching. Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+ Acked-by: Michael Spiceland <mspiceland at digium.com> Acked-by:
+ Russ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Use in-hardirq version of
+ dahdi_receive/transmit. We are already in hardirq context and can
+ therefore save the cli/sti call. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: __t4_framer_in and
+ __t4_framer_out speedups. Speeds up these calls primarily by
+ eliminating unnecessary flushes of writes to the PCI bus. Before:
+ 7.095 us | __t4_framer_in(); 5.835 us | __t4_framer_out(); 7.122
+ us | __t4_framer_in(); 7.071 us | __t4_framer_in(); 7.059 us |
+ __t4_framer_in(); 5.859 us | __t4_framer_out(); 7.076 us |
+ __t4_framer_in(); 5.852 us | __t4_framer_out(); 7.124 us |
+ __t4_framer_in(); 7.080 us | __t4_framer_in(); After: 1.694 us |
+ __t4_framer_out(); 1.686 us | __t4_framer_out(); 1.695 us |
+ __t4_framer_out(); 3.182 us | __t4_framer_in(); 3.283 us |
+ __t4_framer_in(); 2.889 us | __t4_framer_in(); 2.942 us |
+ __t4_framer_in(); 2.951 us | __t4_framer_in(); 2.906 us |
+ __t4_framer_in(); Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove 'pedanticpci'
+ module parameter. The 'pedanticpci' module parameter, which is
+ always on by default, inserts extra reads from the card in order
+ to ensure that all writes are properly flushed through any PCI
+ bridges which may post the writes. The side effect is that this
+ takes more CPU time for registers reads and writes, especially to
+ the framer registers. It is never recommended to run with
+ pedanticpci set to 0, so I'm removing it as a module parameter so
+ that the default case does not take a performance hit checking
+ for whether the parameter is set or not. Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove some debug
+ information from the kernel logs. Also has the nice side effect
+ of eliminating a comparison from the interrupt handler.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Acked-by:
+ Michael Spiceland <mspiceland at digium.com> Acked-by: Russ
+ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Slow down the rate we poll
+ the framers in alarm. The overhead of reading the framer
+ registers is significant and can result in latency bumps / data
+ drops on heavily loaded systems. Instead of checking all spans
+ every millisecond when they are in alarm we will instead only
+ check every 100 ms. On one test system, dropped the % CPU time
+ spent in hard interrupt context from 10% per TDM4XX when all four
+ spans are in alarm to closer to 2%. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Move "hardware DTMF
+ disabled" message from dev_notice -> dev_info This is the
+ "normal" condition and can be lumped with the other informational
+ messages. Otherwise, just this one message might go to the
+ console depending on the system configuration which can be
+ confusing. Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+ Acked-by: Michael Spiceland <mspiceland at digium.com> Acked-by:
+ Russ Meyerriecks <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wctdm24xxp/wctdm24xxp.h: wctdm24xxp: Remove
+ DEBOUNCING_RINGING_OFF from ring_detector_state enum. This value
+ is not used and is now gone. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * drivers/dahdi/wctdm24xxp/base.c: wctdm24xxp: Setup all VPMADT032
+ channels on hybrid cards. r10160 "wctdm24xxp: Probe for and
+ configure modules in parallel." did not properly setup the
+ VPMADT032 for all ports on hybrid cards. The most immediate
+ sympton being that spans 3 and up on a hybrid card would not come
+ up in Asterisk even though they were out of alarm. This was
+ because the echo canceler was blocking messages on the dchannels.
+ This does not affect any previously released versions of
+ DAHDI-Linux or users of the VPMOCT032. Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * include/dahdi/kernel.h, drivers/dahdi/wctdm24xxp/base.c: dahdi:
+ Add functions for determining spantype (E1/T1) to
+ include/dahdi/kernel.h Uses the linecompat member to determine
+ what type of span it is. This will allow removing T1/E1 flags
+ from other places where the span type is stored. This function
+ also changes the return value from bool to int for the inlines
+ defined in include/dahdi/kernel.h. This is because not all kernel
+ versions include stdbool.h in the headers and it will conflict
+ with boolean values that are exported via module parameters on
+ some older kernels if dahdi included it globally. Signed-off-by:
+ Shaun Ruffell <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+ * include/dahdi/kernel.h: dahdi: Define pr_xxx macros if not
+ already defined. The pr_ macros are the recommended way for
+ subsystems to print messages but not all kernel versions DAHDI
+ support has them defined. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Michael Spiceland
+ <mspiceland at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+2011-10-12 16:12 +0000 [r10220] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Fix condition where
+ hardware echo canceler erroneously mutes DTMF. Commit r9750
+ "wct4xxp: Reduce the memory footprint of the hardware
+ echocanceler.", as part of reducing the non-pageable memory
+ required to support the VPMOCT064 and VPMOCT128, disabled caching
+ of some hardware echocan registers. This resulted in more
+ physical reads to the echo canceler. These new read transactions
+ exposed an existing issue where sometimes reads could be turned
+ into writes which put a channel into an unintended state
+ preventing Asterisk from detecting any DTMF. This issue is
+ resolved by ensuring that the write signal to the Octasic part is
+ explicitly cleared between when the address is presented on the
+ bus and when the read and chip select signals are asserted. The
+ cost is an increase in the average time to enable / disable echo
+ cancellation by about 5 us on one Intel Xeon X3220 test machine
+ (~250ns increase per read from the Octasic part and 20 reads to
+ enable / disable a channel). This commit resolves a behavioral
+ regression first introduced in 2.5.0 and 2.4.1 which could take
+ many calls before revealing itself. This change only affects
+ cards with a VPMOCT128 or VPMOCT064 installed. Signed-off-by:
+ Shaun Ruffell <sruffell at digium.com> Acked-by: Doug Bailey
+ <dbailey at digium.com>
+
+2011-09-30 19:12 +0000 [r10218] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wctc4xxp/base.c: wctc4xxp: Allow G723 SID frames to
+ pass to the hardware decoder. The driver has, until now, dropped
+ G723 SID frames even though the firmware on the TC400/TCE400 can
+ handle them. Now let them on through. Reported-and-Tested-by:
+ Angel Carhuas <acarhuas at colinanet.com> Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com>
+
+2011-09-29 16:11 +0000 [r10212] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wcte12xp/base.c: wcte12xp: Set uncollected
+ performance counters to -1. The intent here is to flag to users
+ that the maintenance counters are not collected for spans
+ exported by the wcte12xp driver. dahdi_maint before this change:
+ # dahdi_maint -s 1 Span 1: >Framing Errors : 0: >CRC Errors : 0:
+ >Code Violations : 0: >E-bit Count : 0: >General Errored Seconds
+ : 0: And after: # dahdi_maint -s 1 Span 1: >Framing Errors : -1:
+ >CRC Errors : -1: >Code Violations : -1: >E-bit Count : -1:
+ >General Errored Seconds : -1: This can be combined with a change
+ to dahdi_maint to recognize that the errors are -1 and print an
+ even more explicit warning. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com> Acked-by: Russ Meyerriecks
+ <rmeyerriecks at digium.com>
+
+2011-09-27 22:08 +0000 [r10210] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/wctdm24xxp/base.c: wctdm24xxp: Set
+ dahdi_span.devicetype string in one place. Currently, the
+ devicetype string was set both when the device was first
+ allocated and updated when an echocanceler was detected. For
+ simplicity, combine both these steps into a single function. This
+ change also replaces an improper use of strncat with strlcat.
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com>
+
+2011-09-27 17:10 +0000 [r10209] Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/card_fxs.c: xpp: fix FXS D DTMF detection (not
+ zero) * 'D' DTMF digits were accidentally discarded with the
+ notice message: "Bad DTMF value 0. Ignored". * No need for an odd
+ 1-based translation table anymore - it's 0-based. Signed-off-by:
+ Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+2011-09-23 20:18 +0000 [r10203-10205] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: Check for master in
+ DAHDI_STARTUP / resolves MeetMe regression. There were a couple
+ of reports that MeetMe conferences were not working in 2.5.0.1
+ and that downgrading to 2.4.1.2 resolved the issue. This could
+ occur if there were no analog spans in a system, and all the
+ digital spans were out of alarm before DAHDI_STARTUP ioctl was
+ called by dahdi_cfg. If the spans were *not* out of alarm, they
+ would be marked master when the span changes it's alarm state.
+ This would result in a condition where no spans were marked as
+ the "master" and so the core timer was handling conferencing. The
+ core timer runs by default at 4ms and most board drivers run at
+ 1ms intervals, but a channel currently only buffers up 2ms of
+ data when conferenced. Therefore, 2ms of audio from a board was
+ continuously dropped from the conference every 4ms by default.
+ This fixes a regression first introduced in 2.5.0 which was
+ specifically added in revision r9611 "dahdi: Do not locate new
+ master in interrupt context." Internal-reference-ID: DAHDI-894
+ Signed-off-by: Shaun Ruffell <sruffell at digium.com> Tested-by:
+ Dennis Martinez <dmartinez at digium.com>
+
+ * drivers/dahdi/wct4xxp/base.c: wct4xxp: Remove unused
+ t4_span.psync and t4_span.redalarms. These members are not used
+ anywhere and are now gone. Signed-off-by: Shaun Ruffell
+ <sruffell at digium.com>
+
+ * drivers/dahdi/wcte12xp/base.c, drivers/dahdi/wctdm24xxp/base.c:
+ wctdm24xxp, wcte12xp: Advertise VPMOCT032 presence in
+ dahdi_span.devicetype. A "(VPMADT032)" string is appended to the
+ devicetype (as shown by dahdi_scan) for the span if one is
+ installed. Now append '(VPMOCT032)' if one is installed as well.
+ Also, for the wcte12xp driver append the VPM name to the device
+ type after initially probing as opposed to only after the span is
+ configured. (Related to issue DAHDI-890) Signed-off-by: Shaun
+ Ruffell <sruffell at digium.com>
+
+2011-09-22 18:55 +0000 [r10202] Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+ * drivers/dahdi/xpp/card_fxs.c: xpp: fxs: bugfix for 2fxs+6fxo
+ cards * Bug sympthoms: wrong FSK VMWI sent few seconds after
+ offhook. That was caused because the driver kept polling the
+ (physically unconnected) digital inputs. [note: a workaround for
+ drivers without this patch is to zero the
+ 'xpd_fxs.poll_digital_inputs' parameter.] * Also, the
+ digital_inputs/digital_output masks were calculate using a
+ different condition. * Now we determine number of channels,
+ digital inputs and digital outputs in a single place and use this
+ info later to calculate the correct masks. * We poll only if
+ there are digital_inputs * We added a sanity check in
+ process_digital_inputs, so we get a notice if it's called on an
+ xpd without digital inputs (e.g: hypothetic firmware bug).
+ Signed-off-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com> Acked-by:
+ Tzafrir Cohen <tzafrir.cohen at xorcom.com>
+
+2011-09-13 18:28 +0000 [r10200] Shaun Ruffell <sruffell at digium.com>
+
+ * drivers/dahdi/dahdi-base.c: dahdi: Decrease the initial coretimer
+ delay to 4ms from 1 second. DAHDI currently waits a second before
+ checking if a board driver is calling dahdi_receive and switching
+ to internal timing. Some versions of Asterisk (I was looking at
+ 1.4.42 when writing this) only wait 300ms for a timer to expire
+ when first starting and verifying that DAHDI is properly
+ configured. This can result in a "ERROR[27673] asterisk.c:
[... 5100 lines stripped ...]
More information about the svn-commits
mailing list