Give rest of clock interrupt code a revamp. Because we are using an external
cycle counter we can now handle loosing several hundred interrupts without
the time slipping.
If the machine uses a Z85230 ESCC device with deep buffers, we observe
output glitches when printing the zstty{0,1} probe lines when the device
is reset & reprogrammed during startup.
There is no easy 'hook' in the MI Z8530 driver, so we wait for output
buffer to drain before changing the baud rate generator prescaler value.
If the DMA chaning interrupt couldn't be serviced immediately (higher spl
level when kernel doing something else) a few microseconds later the NCR
controller will fill its FIFO and also interrupt the CPU.
The SCSI interrupt sees the terminal count has been reached, calls
asc_dma_intr to finish the job off. The FIFO cannot be flushed because
the block count hasn't been setup for the last dma segment (DMA chaining
still wasn't serviced).
Since the NCR 53c94 FIFO is only 16 bytes in size, any short DMA in this
size combined with the machine 'doing something else' causes the problem
to occur.
Servicing the DMA chaining interrupt before the NCR SCSI interrupt solves
this problem.
Add tests to ensure the DMA FIFO has been flushed correctly at the end of
each DMA operation just to be on the safe side.
- Using the prom getenv function determine the correct console port
- Remove old prom function hooks
- Tidy up bootflags (remove upper case names, fixup RB_ASKNAME) as
recommended by Jaromír Doleèek
handler to hook up device interrupts and softc callbacks.
Suggested by: Jason Thorpe and Toru Nishimura
* Fixup the indenting in a few places to conform to NetBSD style
the DMA FIFO on non block aligned writes. Not doing this causes large
writes (>4k) that are not aligned to incorrectly write 64bytes
of data every 4k interval. This only occurs on raw devices - typically
newfs fails to create a clean filesystem.
wdk