Sunix 4056A PCI 4 port RS-232 card - only 2 ports configured

[John Baldwin]

On Thursday, May 26, 2011 9:42:11 am N.J. Mann wrote:
> Hi Marcel,
> 
> 
> In message <803C09E5-8E10-4289-A8B3-952E8A72C7A1 at xcllnt.net>,
> 	Marcel Moolenaar (marcel at 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);


-- 
John Baldwin