>> [testing gdamore-uart stuff]
> What you are testing is serial performance.

Inbound?  Outbound?  Both?  Any particular performance metrics?  Max
speed sustainable?  Interrupt CPU percentage for a given speed?  Error
rate for a given speed?

AIUI the code change in question would basically slow down all driver
access to the chip, so any of the above would be worth checking - is
this at least approximately correct?

> If you have a way to measure that directly, it would be optimal.

Well, if there's no output buffer to speak of, I could just pump data
out (to nothing) and crank up the baud rate until interrupt CPU time
hits 100%.

> If you'd like, I can post a kernel on ftp.netbsd.org.

That would be very helpful - but don't bother until I've verified that
the board I have works.  (I'm in a time crunch right now between work
running a bit late and a friend dropping by, so I can't check now.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B