Subject: CVS commit: src/sys/arch/sgimips/hpc
To: None <source-changes@NetBSD.org>
From: Steve Rumble <rumble@netbsd.org>
List: source-changes
Date: 12/29/2004 06:57:52
Module Name: src
Committed By: rumble
Date: Wed Dec 29 06:57:52 UTC 2004
Modified Files:
src/sys/arch/sgimips/hpc: if_sq.c
Log Message:
Fix the HPC1 transmit logic, which was previously very broken.
HPC1 does not mark transmitted descriptors like HPC3. We must
query the HPC1 chip to determine what it expects the next
descriptor to be, reclaim used ones, and restart if necessary. Each
revision's corresponding logic now lives in its own
sq_txring_hpc{1,3} function.
HPC1's transmit interrupt conditions also differ from HPC3, so
remove the INTR bits from descriptors when tagging new packets on
to the end of the chain in order to avoid unwanted interrupts.
Also, be extra careful when restarting the transmit ring. Since
transmit interrupts seem to be relatively slow on HPC1, sq_start
may be called while the DMA engine is quiescent, and before a
transmit interrupt is asserted. We cannot behave like HPC3, which
begins transmission from the first packet pulled from IFQ if the
DMA engine is quiescent as this would skip enqueued packets. It
appears that sq_start is never called before HPC3 asserts an
interrupt, which restarts the transmit queue at the appropriate
place. However, this often happens with HPC1 and we cannot assume
that if DMA is inactive in sq_start, then all previously queued
packets have fled the coop.
XXX Is there a similar race possible with HPC3?
HPC3 logic should remain functionally unchanged, and HPC1 should
finally work properly.
To generate a diff of this commit:
cvs rdiff -r1.22 -r1.23 src/sys/arch/sgimips/hpc/if_sq.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.