Bill Paul 9a65a1c94d Perform an RX reset and TX reset in xl_reset() along with the master
reset command.

I observed some anomalous behavior while testing a 3c905C with a
Dell PowerEdge 4300/500 dual PIII 500Mhz system. The NIC would seem
to work correctly most of the time but would sometimes fail to receive
certain packets, in particular NFS create requests. I could mount
an NFS filesystem from the PowerEdge and do an ls on it, but trying
to do a "touch foo" would hang. Monitoring traffic from another host
revealed that the client was properly sending an NFS create request
but the server was not receiving it. It *did* receive it when I
ran the same test with an Intel fxp card.

I don't understand the exact mechanics of this strange behavior, but
resetting the receiver and transmitter seems to get rid of it. I used
to perform an RX and TX reset in xl_init(), but stopped doing it there
because on 3c905B and later cards this causes the autoneg session to
restart, which would lead to the NIC waiting a long time before exchanging
traffic after being brought up the first time. Apparently the receiver
and transmitter resets should be performed at least once when initializing
the card.

Hopefully this will cure problems that people have been having with the
3c905C -- this was the only strange behavior that I have observed with
the 3c905C so far which does not appear with the 3c905B or 3c905.
1999-08-02 21:06:16 +00:00
..
1999-07-12 15:51:50 +00:00
1999-07-12 15:51:50 +00:00
1998-06-13 17:20:03 +00:00
1998-01-26 06:11:18 +00:00
1999-07-06 19:23:32 +00:00
1999-07-06 19:23:32 +00:00
1999-07-06 19:23:32 +00:00
1999-07-06 19:23:32 +00:00
1999-07-28 02:19:52 +00:00
1999-07-28 02:19:52 +00:00
1999-07-06 19:23:32 +00:00
1999-07-06 19:23:32 +00:00
1998-09-15 08:21:13 +00:00
1999-06-16 17:34:36 +00:00
1999-07-13 08:15:22 +00:00

-------------------------------------------------------------------------------
Recent versions of 3.0-current have the bktr driver built in.  Older versions
of 3.0 and all versions of 2.2 need to have the driver files installed by hand:

cp ioctl_bt848.h /sys/i386/include/
cp brktree_reg.h brooktree848.c /sys/pci/

In /sys/conf/files add:
pci/brooktree848.c        optional bktr device-driver

-------------------------------------------------------------------------------
In all cases you will need to add the driver to your kernel:

In your kernel configuration file:
controller      pci0     #if you already have this line don't add it.
device          bktr0    

There is no need to specify DMA channels nor interrupts for this
driver.

-------------------------------------------------------------------------------
Finally you need to create nodes for the driver:

Create a video device:
mknod /dev/bktr0 c 92 0

Create a tuner device:
mknod /dev/tuner0 c 92 16

-------------------------------------------------------------------------------
The code attempts to auto-probe code to detect card/tuner types.
The detected card is printed in the dmesg as the driver is loaded.  If
this fails to detect the proper card you can override it in brooktree848.c:

#define OVERRIDE_CARD	<card type>

where <card type> is one of:
	CARD_UNKNOWN
	CARD_MIRO
	CARD_HAUPPAUGE
	CARD_STB
	CARD_INTEL

-------------------------------------------------------------------------------
This model now separates the "tuner control" items into a minor device:

minor device layout:  xxxxxxxx xxxT UUUU

 UUUU:   the card (ie UNIT) identifier, 0 thru 15
 T == 0: video device
 T == 1: tuner device

Access your tuner ioctl thru your tuner device handle and anything
which controls the video capture process thru the video device handle.

Certain ioctl()s such as video source are available thru both devices.

-------------------------------------------------------------------------------
If your tuner does not work properly or is not recognized properly
try setting the tuner type via or card type:
sysctl -w hw.bt848.card=<integer> current valid values are 0 to 5 inclusive
sysctl -w hw.bt848.tuner=<integer> where integer is a value from 1 to 10
systcl -w hw.bt848.reverse_mute=<1 | 0> to reverse the mute function in the
                                driver set variable to 1.
The exact format of the sysctl bt848 variable is:
unit << 8 | value

unit identifies the pci bt848 board to be affected 0 is the first bt848 
board, 1 is the second bt848 board.
value denotes the integer value for tuners is a value from 0 to 10 for
reversing the mute function of the tuner the value is 1 or 0.

to find out all the bt848 variables:
sysctl hw.bt848



-------------------------------------------------------------------------------
The bt848 driver consists of:

src/sys/i386/include/ioctl_bt848.h
src/sys/pci/brktree_reg.h
src/sys/pci/brooktree848.c