* Add support for 5704C dual-channel chip with integral copper PHY (tested)
and 5704S dual-channel SERDES/TBI gbic (untested). Add PHY DSP patch
for 5704.
* Update PHY DSP-code patch for bcm5401 to match latest Linux driver.
* Add PHY DSP-code patch for 5703 (untested).
* Update onchip buffer tunables to recommended values from Linux drivers.
* Disable MWI access. This chip family cannot hanlde PCI stalls
in the middle of an MWI burst. The driver has heuristics to detect PCI
line size, but under load, some PCI bridges may force stalls which
the attach-time heruistics do not catch. Some PCI bridges never
do this, so maybe it should be a tunable option.
* bcm5700 rev Bx chips have a race condition, where updating the
Tx producer pointer goes un-noticed by the chip. Workaround is to
write the new producer-pointer value twice.
* bcm5700 chips rev Bx wedge up if given DMA descriptors of
eight bytes or less. Once hit, only reovery is a watchdog timeout/reset.
If the offending packet is retransmitted, the chip will wedge again...
Check for teeny fragments in a Tx request, and either fold the
teeny chunk residue into an adjacent mbuf, or m_dup the entire buffer.
(NB: quirk not yet enabled; in-place folding tested only on FreeBSD.)
* Add workaround for revision Bx bcm5700: chip bugs in decoding
of PCI register writes may leave the hardware in (partial) powersave state,
such that writes to "indirect" registers do not work.
Explicitly force chip into D0 state at attach time.
* Accessing PHY registers with the bge chip in autopoll mode, when
link-state is the process of changing, may cause the bge chip to
assert PCI errors. Workaround: when doing miibus register access,
save autopoll state, disable around access, and restore autopoll state.
NB: issuing PHY resets may give a window where the problem still occurs.
* Increase Tx interrupt-coalescing thresholds, to reduce Tx-done interrupts.
XXX should it be ETHER_MIN_LEN - ETHER_CRC_LEN ?
XXX2 we assume there are enouth space in the mbuf for the padding bytes.
But other places in the code assumes this already.
auich_set_rate() modified audio_params::sample_rate to actual
sample rate though auich_set_params() rejected sample rates
other than some specific rates. For example, setting 8000Hz
with auich_set_params() modified sample_rate to 7998Hz in the
case of overclocked AC97 codec, and calling auich_set_params()
again returned with EINVAL because sample_rate was 7998Hz and
auich_set_params() rejected 7998Hz.
For now, auich_set_params() never modify audio_params::sample_rate.
and the back end Bluetooth device driver. The device driver now
allocates a suitable buffer on behalf of the bthci driver, and bthci
fills the buffer before despatch.
This saves an ugly temporary allocation (in bthci) and memory copy (in
the USB driver) per write, and also works better with the
sockets-based interface I'm experimenting with.
