Always init chip via I/O space.
Map only I/O registers we actually need.
Automatically detect if we need to do bswapping
Add (untested) code to use automagic bswap on CyberPro.
Report video memory amount.
Report if/how bswapping is done.
When initializing a TCP/IP context descriptor, even if a checksum
offload feature is not going to be used, the IPCSS and TUCSS fields
must be initialized.
the brgphy driver; all users of the BCM5400 and BCM5401 need
the DSP patch and the sledgehammer-reset-at-media-set-time.
Also add a DSP patch for the BCM5411 gleaned from Apple's
GMAC driver for Darwin.
Tested with a 3Com 3c996-T (BCM5700 + BCM5401).
* Fix outbound IPv4 header checksums (missing add of an offset).
* When enabling Rx TCP/UDP checksum offload, make sure that IPv4
header checksum Rx offload is enabled on the chip, as well.
* Bump the number of Rx descriptors from 128 to 256.
* Don't use a sliding Tx interrupt window. Instead, just do reap-behind
when we have <= 1/8 of our available descriptors in wm_start().
* Don't use Tx Queue Empty interrupts, and always set the Tx Interrupt
Delay bit in the Tx descriptor.
* In wm_intr(), always call wm_rxintr() and wm_txintr(), regardless of
their respective ISR bits being set. We're here, might as well do some
work.
* Adjust the Tx and Rx interrupt delay timer values. New values from
Intel's driver for FreeBSD via Allen Briggs.
With these changes, NetBSD can sustain > 900Mb/s userland to userland
*without* using TCP checksum offload using Intel PRO/1000 XT cards.
to enable 64-bit data transfers on 64-bit cards when plugged into
a 64-bit slot. Right know the Asante GigaNIX is listed in that
table.
Sigh, there is an EEPROM bit that can be used to detect 64-bit vs
32-bit cards. Unfortunately, at least 2 vendors of 32-bit cards
fail to clear the "DATA64_EN" bit in the EEPROM, which causes the
card to lose badly, because it still manages to detect that it's
plugged into a 64-bit PCI slot. Yay, stupid hardware vendors.
path: Instead of waiting for the if_snd queue to be drained before
giving ownership of the frist descriptor to the chip, do it after
sync'ing all the descriptors for a single packet.
* Get CFG_M64ADDR, CFG_T64ADDR, and CFG_DATA64_EN from the EEPROM.
Note, we still disable CFG_M64ADDR and CFG_T64ADDR later (XXX need
PCI bus capability flags for these).
* Print a message if we're in a 64-bit slot and 64-bit data is
disabled in the EEPROM. Make sure CFG_DATA64_EN is disabled if
we're not in a 64-bit slot.
-treat the builtin font like any other font at runtime
-for that, copy it to malloc()'d memory during attach()
-in early console initialization, if we have to consider a broken card
(VGA_CONSOLE_ATI_BROKEN_FONTSEL), copy the builtin font to another
location in font ram; the attach() code will do the rest
put the "quirk" code into effect again
bit and then read it back in a loop (with appropriate delays) waiting
for it to read back clear.
This fixes a problem where the bus would hang when bringing down
the interface or changing interface flags on a system with a
sufficiently fast CPU (e.g. 2GHz P4 Xeon).
found on many (all?) of PCI-based ATI graphics cards. It is fully optional
and can be enabled by adding `options VGA_CONSOLE_ATI_BROKEN_FONTSEL'
to config file.
- Temporarily remove `quirk' mechanism. Similar code already exists
in pci_quirks.c.
make the number of available font slots variable,
set up a "quirk" mechanism to tell the generic vga code about crippled
VGA adapters which ignore the "fontsel" TS register,
initiate the quirk table with an ATI chip which happened to be on a board
I tested with.
Afaik quite a number of ATI chips suffers from the "loaded fonts don't
work" problem - these should be added.
Bad side effect of my change: The builtin font will be kicked out
always if a VGA_CONSOLE_SCREENTYPE is specified which needs a loaded
font. In early console initialization, we don't know much about the
graphics card, so we have to assume the worst (ie ATI:-).
Written by Bill Paul for FreeBSD. This port started out with the
port done to OpenBSD by nate@openbsd.org, but ended up looking much
more like the port of the ti driver done by drochner@netbsd.org
(they are similar in structure).
kent