Overhaul bus_dma(9) usage in driver:

 - Don't use a single big DMA block for all rings. Create separate
   DMA area for each ring instead.  Currently the following DMA
   areas are created:
	Event ring, standard RX ring, jumbo RX ring, RX return ring,
	hardware MAC statistics and producer/consumer status area.
   For Tigon II, mini RX ring and TX ring are additionally created.
 - Added missing bus_dmamap_sync(9) in various TX/RX paths.
 - TX ring is no longer created for Tigon 1 such that it saves more
   resources on Tigon 1.
 - Data sheet is not clear about alignment requirement of each ring
   so use 32 bytes alignment for normal DMA area but use 64 bytes
   alignment for jumbo RX ring where the extended RX descriptor
   size is 64 bytes.
 - For each TX/RX buffers use separate DMA tag(e.g. the size of a
   DMA segment, total size of DMA segments etc).
 - Tigon allows separate DMA area for event producer, RX return
   producer and TX consumer which is really cool feature.  This
   means TX and RX path could be independently run in parallel.
   However ti(4) uses a single driver lock so it's meaningless
   to have separate DMA area for these producer/consumer such that
   this change creates a single status DMA area.
 - It seems Tigon has no limits on DMA address space and I also
   don't see any problem with that but old comments in driver
   indicates there could be issues on descriptors being located in
   64bit region.  Introduce a tunable, dev.ti.%d.dac, to disable
   using 64bit DMA in driver. The default is 0 which means it would
   use full 64bit DMA.  If there are DMA issues, users can disable
   it by setting the tunable to 0.
 - Do not increase watchdog timer in ti_txeof(). Previously driver
   increased the watchdog timer whenever there are queued TX frames.
 - When stat ticks is set to 0, skip processing ti_stats_update(),
   avoiding bus_dmamap_sync(9) and updating if_collisions counter.
 - MTU does not include FCS bytes, replace it with
   ETHER_VLAN_ENCAP_LEN.

With these changes, ti(4) should work on PAE environments.
Many thanks to Jay Borkenhagen for remote hardware access.

0 files changed, 0 insertions, 0 deletions