garrett_damore@tadpole.com wrote:

> I intend to merge gdamore-uart branch, which includes my changes to make
> com(4) work better with devices like Alchemy's onboard UARTs (adding
> conditionally-compiled in indexed register accesses).  I've done compile
> testing on all ports, and all ports with com ports seem to compile
> reasonably well.  I've tested com(4) for basic functionality to 115200
> on those ports that I could test.  (I don't have any lower end 386 or
> fifoless parts.)

Did you try kernels with options COM_REGMAP for existing com devices
which take com_std_map?

I tested a kernel with options COM_REGMAP for com_dio on my hp425t
(68040 25MHz) but it doesn't probe com properly (probed as 16450
rather than 16550a) and doesn't work. (I haven't checked details yet)

> I will wait one week, and then merge on 7/12/06 if no one objects.   If
> you are concerned about com(4) performance and have the ability to test,
> please do so before then and report any negative results.  Otherwise its
> going in. :-)

I mesured xfer rate via SLIP (9600bps, RTS/CTS flow control)
on getting a 1.8MB file from i386 by ftp(1):
 GENERIC on HEAD:		0.76KB/s (with 8 overflows)
 GENERIC on gdamore-uart:	0.75KB/s (with 6 overflows)
There seems some difference (caused by indirection of tag and handles?),
but it's acceptable for me. The machine is slow enough anyway and
higher baud rate causes much overflows even on current kernels.
---
Izumi Tsutsui