From owner-freebsd-hardware@FreeBSD.ORG Thu May 26 20:22:05 2011 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 087051065672 for ; Thu, 26 May 2011 20:22:05 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp003.apm-internet.net (smtp003.apm-internet.net [85.119.248.52]) by mx1.freebsd.org (Postfix) with SMTP id 710828FC0A for ; Thu, 26 May 2011 20:22:04 +0000 (UTC) Received: (qmail 56098 invoked from network); 26 May 2011 20:22:03 -0000 Received: from unknown (HELO oberon.njm.me.uk) (86.144.179.173) by smtp003.apm-internet.net with SMTP; 26 May 2011 20:22:03 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.4/8.14.4) with ESMTP id p4QKM2TA039888; Thu, 26 May 2011 21:22:02 +0100 (BST) (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.4/8.14.4) with ESMTP id p4QKM2Ar037502; Thu, 26 May 2011 21:22:02 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.4/8.14.4/Submit) id p4QKM21I037501; Thu, 26 May 2011 21:22:02 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Thu, 26 May 2011 21:22:01 +0100 From: "N.J. Mann" To: John Baldwin Message-ID: <20110526202201.GA29605@titania.njm.me.uk> Mail-Followup-To: John Baldwin , Marcel Moolenaar , freebsd-hardware@freebsd.org References: <20110522110002.GB91694@titania.njm.me.uk> <803C09E5-8E10-4289-A8B3-952E8A72C7A1@xcllnt.net> <20110526134211.GB9481@titania.njm.me.uk> <201105261139.16839.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105261139.16839.jhb@freebsd.org> X-Operating-System: FreeBSD 8.2-STABLE User-Agent: mutt-NJM (2010-10-31) Cc: freebsd-hardware@freebsd.org, Marcel Moolenaar Subject: Re: Sunix 4056A PCI 4 port RS-232 card - only 2 ports configured X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 20:22:05 -0000 In message <201105261139.16839.jhb@freebsd.org>, John Baldwin (jhb@freebsd.org) wrote: > On Thursday, May 26, 2011 9:42:11 am N.J. Mann wrote: > > Hi Marcel, > > > > > > In message <803C09E5-8E10-4289-A8B3-952E8A72C7A1@xcllnt.net>, > > Marcel Moolenaar (marcel@xcllnt.net) wrote: > > > > > > On May 25, 2011, at 6:46 AM, John Baldwin wrote: > > > > > > *snip* > > > > > > >> For the two devices that fail, ns8250_bus_probe() fails on the first > > > >> call: > > > >> > > > >> UART4 > > > >> ----- > > > >> ns8250_bus_probe:: entry > > > >> ns8250_probe::uart_getreg REG_IIR = 1 > > > >> ns8250_probe::uart_getreg REG_MCR = 64 > > > >> ns8250_bus_probe::ns8250_probe returned 6 > > > >> > > > >> UART5 > > > >> ----- > > > >> ns8250_bus_probe:: entry > > > >> ns8250_probe::uart_getreg REG_IIR = 1 > > > >> ns8250_probe::uart_getreg REG_MCR = 64 > > > >> ns8250_bus_probe::ns8250_probe returned 6 > > > >> > > > >> The value returned for the read of REG_MCR is 64, or 0x40, which causes > > > >> the premature exit: > > > >> > > > >> static int > > > >> ns8250_probe(struct uart_bas *bas) > > > >> { > > > >> u_char val; > > > >> > > > >> /* Check known 0 bits that don't depend on DLAB. */ > > > >> val = uart_getreg(bas, REG_IIR); > > > >> if (val & 0x30) > > > >> return (ENXIO); > > > >> val = uart_getreg(bas, REG_MCR); > > > >> if (val & 0xe0) > > > >> return (ENXIO); > > > >> > > > >> return (0); > > > >> } > > > >> > > > >> Do you need to know the contents of 'bas'? > > > > > > > > This goes beyond my level of knowledge. I've cc'd Marcel (author of > uart) who > > > > can hopefully help with this more. > > > > > > The ns8250 family of UARTs typically have bits 5, 6 and 7 of the > > > MCR register reserved and thus hardwired to 0. The probe function > > > checks for that to make sure that the hardware looks enough like > > > a UART that we can claim it without hosing the box. > > > > > > That said: newer chips in the family, like the ST16C850/XR16C850, > > > have given those bits a function: > > > bit 5 - Xon-Any enable > > > bit 6 - Infrared enable > > > bit 7 - Clock pre-scaler > > > > > > It's unclear to me whether those bits are consistently defined > > > across the different implementations (for some reason I think > > > not) and it's also unclear to me whether the device will work > > > correctly with FreeBSD if we simply ignore those bits (again I > > > don't think this is always the case). > > > > > > I think the first order of business from an architectural point > > > of view is to determine how much value register probing still has > > > on modern hardware. In the good old days, this was needed. If > > > we think it's not really needed anymore, then it makes sense to > > > loosen the grip so to speak. > > > > > > For you, the first thing is to see whether the UART ports work > > > if you tweak the probe functions, like so: > > > > > > Index: uart_dev_ns8250.c > > > =================================================================== > > > --- uart_dev_ns8250.c (revision 222217) > > > +++ uart_dev_ns8250.c (working copy) > > > @@ -243,7 +243,7 @@ > > > if (val & 0x30) > > > return (ENXIO); > > > val = uart_getreg(bas, REG_MCR); > > > - if (val & 0xe0) > > > + if (val & 0xa0) > > > return (ENXIO); > > > > > > return (0); > > > > I tried this and the result is that ports 3 and 4 now attach okay. > > However, the baud rate of these two is wrong. If I select 9600 they > > actually send and receive at 1200, i.e. eight times slower. The speed > > setting for the first two ports is correct. (I checked all four ports at > > 9600, 38400 and 115200.) > > Ah, there are other reports of this: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056533.html > > I think this patch should fix the timing issue: > > Index: pucdata.c > =================================================================== > --- pucdata.c (revision 222285) > +++ pucdata.c (working copy) > @@ -1292,6 +1292,12 @@ puc_config_timedia(struct puc_softc *sc, enum puc_ > uint16_t subdev; > > switch (cmd) { > + case PUC_CFG_GET_CLOCK: > + if (port < 2) > + *res = DEFAULT_RCLK * 8; > + else > + *res = DEFAULT_RCLK; > + return (0); > case PUC_CFG_GET_DESC: > snprintf(desc, sizeof(desc), > "Timedia technology %d Port Serial", (int)sc->sc_cfg_data); > Yes, that fixed it. All ports are working correctly now. Many thanks. Cheers, Nick. --