_cpu_exception_suspend()/_cpu_exception_resume() pair.
Should fix spontaneous reboot problem on heavy load reported by
Christian Groessler on port-dreamcast.
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.
true on the transmit side, which appears to be significantly slower at
interrupting than HPC3.
XXX I used to be able to occasionally wedge the chip with
SQ_NTXDESC == 32, but have not yet been able to reproduce that
behaviour this evening with a larger value.
multiple seeq interfaces may exist. While here, add a few trace
actions, move the related macros into sqvar.h, and enhance the
sq_trace_dump output a bit.
is always aligned. This makes md_root_loadaddr always 4 byte aligned.
Without this, may get an un-aligned access trap before we even print
anything on the console which was a pain in the neck to debug since so
early in the bootstrap the CPU usually just halts on exceptions.
