dahdi: Increase the number of conference buffers to eight.

When DAHDI is bridging channels between two different cards, or a user is trying
to record from a channel on a card that is not using the same timing source as
the master span, it is possible to miss audio.

For example, given the following scenario:

<T1 Span> <---> <ISDN CARD> <---> <ANALOG CARD> <---> <local handset>

If DAHDI was set to natively bridge the call from the T1 span to the local
handset it is possible that system conditions could result in one of the cards
servicing their interrupt three times before the other card has a chance to.
Since there are currently only two conference buffers to pass audio between the
cards, one chunk (1ms) of audio will be dropped since the card servicing it's
interrupt more frequently will run out of space to copy audio for the other card
and will have emptied the audio buffer from the other card.

Increasing the number of conference buffers to eight greatly reduces the
probability of audio from being dropped under these conditions at cost of an
additional 72 (32-bit) or 96 (64-bit) bytes per DAHDI channel.

Internal-Issue-ID: DAHLIN-159, DAHDI-976
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10726 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Filter 'HWEC' from DAHDI_GETVERSION results if hwec is really not present.

Internally in DAHDI there is always a hardware echocan factory registered and
available. Having this factory always registered allows for DAHDI to work in a
backward compatible fashion. Namely, by default DAHDI will always use a hardware
echocan if one is available unless 'hwec_overrides_swec' dahdi module parameter
is set to 0 on load. However, if there were no real hardware echocans available
in the system dahdi would still report "Echo Canceller(s): HWEC" in the
dahdi_cfg -v output since the hwec factory is always there.

After this change dahdi_cfg will no longer report HWEC as one of the available
echocans if there isn't a physical span present that actually has a hardware
echocan.

Internal-Issue-ID: DAHLIN-300
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10727 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wct4xxp: Ensure all spans are configured by default.

Not configuring all the spans on an octal card can result in some of the
spans not working in clear channel modes.

Now ensure that all spans receive a default configuration regardless how
they are configured from user space.

Internal-Issue-ID: DAHLIN-289
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10728 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wctdm24xxp: Set dahdi_span.spantype to SPANTYPE_ANALOG_MIXED.

Since r10683 "convert span->spantype to enumerated type" [1] the spantype was
changed from a string provided by the board drivers to an enumerated type that
is handled by the core of DAHDI. This was done to simplify the task of
dahdi_genconf since there is only one place to look for the valid strings that
can be exported in sysfs.

This eliminates the following warning on driver load:
  Warning: Span %s didn't specify a spantype. Please fix driver!

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10683

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10729 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Remove unused 'rxbufpolicy' and 'rxdisable' from dahdi_chan.

Since r5021 [1], first released in DAHDI-Linux 2.2.0, it's been impossible for
user space to change the rxbufpolicy. This hasn't caused any problems and it's
safe to remove a few more of the vestiges of the rxbufpolicy from the driver.

This streamlines the code path in a few places and saves 8 bytes from the size
of struct dahdi_chan.

The user visible parts are maintained and will indicate
DAHDI_POLICY_IMMEDIATE, like it has since 2.2.0.

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=5021

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10730 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Remove 'getlin_lastchunk' from struct dahdi_chan.

'getlin_lastchunk' has not been used since r65 "Version 0.1.6 from FTP" [1]

One less thing to think about...

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=65

Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10731 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Running without the Big Kernel Lock (BKL) is no longer experimental.

The warning was originally added in r9721 "dahdi: Experimentally
remove dependency on the Big Kernel Lock." [1].

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=9721

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10732 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wct4xxp: EC channel calculation in TONEDETECT assumes TE820.

Since r10290 "wct4xxp: Add support for TE820 and VPMOCT256." [1],
the TONEDETECT ioctl was not calculating the VPM channel correctly
on non TE820 cards. This fixes a regression first introduced in
2.6.0.

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10290

Internal-Issue-ID: DAHLIN-302
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10733 a0bf4364-ded3-4de4-8d8a-66a801d63aff