cvs commit: src/sys/dev/sab sab.c

[Marius Strobl]

On Wed, Oct 13, 2004 at 01:19:20PM -0700, Marcel Moolenaar wrote:
> On Wed, Oct 13, 2004 at 11:44:22AM +0200, Marius Strobl wrote:
> > > >   
> > > >   Isn't this driver superseeded by uart(4) anyway ?
> > > 
> > > Yes, in principle. I don't think I'm in the position to remove sab(4)
> > > though. 
> > 
> > Uart(4) works fine as a replacement for sab(4) but we're not ready to
> > switch to uart(4) by default on sparc64.
> 
> Z8530 issues, right?
> 

The Z8530 issues are the biggest problem but there are others:
- When both uart(4) and ofw_console(4) are present but the input and output
  are keyboard and screen respectively one ends up with no working console.
  The problem simply is that the OFW keyboard driver no longer works once
  uart(4) attaches to the keyboard port. A quick hack to uart_bus_probe()
  to fail when the UART is the keyboard port but not a sysdev makes both
  uart(4) and ofw_console(4) work happily together. But I'd rather make
  uart(4) attach in sort of a disabled mode in the above case, i.e. claim
  the resources but don't do anything with the UART, so nothing else can
  attach to the respective UART, the user can be told what's going on and
  device numbering is the same whether the keyboard is used directly or
  via OFW.
- Using the second on-board 16550 on the ISA bus of sparc64 machines
  causes a hang, i.e. an endless loop in uart_intr(), as these UARTs
  share the same IRQ, uart(4) successfully registers both handlers as
  fast ones but FreeBSD/sparc64 misses the MD part of shared fast
  interrupt handlers (and also doesn't prevent setting up shared fast
  interrupt handlers). A patch implementing the sparc64 part for shared
  fast handlers is under review.
- There's no support for UARTs on the FHC bus (and for that matter also
  not for powerpc/macio so zs(4) could be entirely replaced), yet. This
  for one requires working Z8530 support but also a uart_bus_fhc.c and
  support for FHC in the sparc64 OF_decode_addr() or better finally a
  rewrite of OF_decode_addr() to be mostly bus-neutral (might even work
  for powerpc then).

If there is a strong desire to remove sab(4) I'd say one could switch
to uart(4) by default on sparc64 once the first two problems above
are solved but one would have to disable support for Z8530 until
uart(4) really supports these or at least don't attach to the Z8530
that are keyboard or mosue ports as those currently causes the most
problems (Z8530 as console port works ok, but ttyb, i.e. the non-
console port of the first SCC doesn't reliably).
As for the Z8530 issues I spent quite a while trying to make it work
without success. I think the main problem is the "special" way uart(4)
work's around the problem that it can't use the interrupt status
register shared between the two channels. But there seem to be other
problems, e.g. according to my break-out box ttyb comes up in wired
states most of the time when the stock uart(4) initilizes it; I got it
to come up in a consistent state by rototilling the initialization to
be as close as possible to the datasheet but then ttyb never worked
(as opposed to sometimes with the stock uart(4)). The hang when
keyboard and mouse are unplugged is caused by an endless stream of
breaks on these ports in this case but for reasons unknown to me I
didn't manage to make the Z8530 to not trigger an interrupt on
non-sysdev ports.
I think the first step to get working Z8530 support is to create an
chip-aware scc(4) (as opposed to puc(4) which mainly is sort of a
resource multiplexer/splitter) but I currently don't really want to
deal with the other aspects of a scc(4) like synchronous mode etc.

Marius