From owner-cvs-all@FreeBSD.ORG Mon Oct 18 20:58:55 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45FBD16A4CE; Mon, 18 Oct 2004 20:58:55 +0000 (GMT) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 923D943D2F; Mon, 18 Oct 2004 20:58:54 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) i9IKwrAZ075334; Mon, 18 Oct 2004 22:58:53 +0200 (CEST) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.10/8.12.10/Submit) id i9IKwlcJ075333; Mon, 18 Oct 2004 22:58:47 +0200 (CEST) (envelope-from marius) Date: Mon, 18 Oct 2004 22:58:47 +0200 From: Marius Strobl To: Marcel Moolenaar Message-ID: <20041018225847.A12117@newtrinity.zeist.de> References: <200410122233.i9CMXJxl047004@repoman.freebsd.org> <20041012225842.GA27757@ns1.xcllnt.net> <20041013114422.A9875@newtrinity.zeist.de> <20041013201920.GA34255@ns1.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041013201920.GA34255@ns1.xcllnt.net>; from marcel@xcllnt.net on Wed, Oct 13, 2004 at 01:19:20PM -0700 X-AntiVirus: checked by AntiVir Milter (version: 1.1; AVE: 6.28.0.7; VDF: 6.28.0.20; host: newtrinity.zeist.de) cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: Poul-Henning Kamp cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/sab sab.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 20:58:55 -0000 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