...and meanwhile back in Gotham City, Matt Thomas (matt) wrote:
> 
> Nope.  I don't seem to have the interrupts working correctly.  It's hard
> to say what's since I can't very well hook a breakout box to the line.
> But since no interrupts are recorded, I figure that's the problem.
> NetBSD/sparc is a new port to me and I'm still figuring out things.
> I checked it in hoping that someone else could make progress while
> I'm stalled.

Hmm, I wonder if the i/o mapping isn't broken in some way?  On boot 
the registers of the 16450 should all read 0x00, but if you stick in
debugging printfs, I'll bet you see 0xff on each one.  Which would imply
that the initializations in com_attach_subr() aren't really happening on
the modem, but rather some random chunk of memory.  This would also explain
the interrupt situation, since if we're not actually writing to the 
interrupt enable register of the fake-16450 in the tadpole, then there's 
little chance of it actually generating interrupts!   Also, this would explain
why it attaches as a 16550 in your code, since it would appear to the 
com code that the FIFO stuff is set -- because *every* bit is set in 0xff.

I saw the same thing with my driver code, and I was in the process of
trying to figure out why the mapping didn't seem to be working; I'd gone as
far as ensuring that data sent to the port was correctly being whacked into
the tty output queue, but it was all hanging, waiting for the tx_empty
interrupt to drain that queue, in order to prove it was the i/o mapping.

So it looks like the problem has something to do with bus_space_map(), 
either in the com_obio code, or else in the mapping for the 4m obio (sbus) 
space itself.

I'm busy rebuilding -current from this afternoon's source, I'll poke on it
more tomorrow.

~james