Port-amiga archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Problems with IOblix serial ports
On Wed, 26 May 2010 21:04:26 +0000 (UTC)
John Klos <john%ziaspace.com@localhost> wrote:
> > So you might try to add
> > options COM_16650
> > to your config file, to improve things (which should be included in
> > the GENERIC file, when it really helps). I'm not absolutely sure
> > about this, but from the com.c source it seems that most(all?)
> > 16650 functions are supported by the 16C654.
>
> I've added this, but didn't see any changes.
Probably the 16650 support is currently broken.
> It was pointed out to me
> by a different brother that the 16C654 should be considered distinct:
>
> "DON'T use the 16550 datasheet to determine the characteristics for
> the 16550 as applying to the 16654.
That's correct. So defining COM_16650 is the right thing to do. Maybe
it needs some additional fixes.
> In com.c it's mentioned that there are other features (such as
> automatic hardware flow control) on the StarTech versions and that
> the National Semiconductor part is handled differently in several
> respects as compared with the StarTech.
Indeed.
Bernd Ernesti pointed to a relevant thread from Takashi Kiyohara where
he probably fixed a bug with 16650 hardware flow control. He also
multiplied the sc_frequency by 4 (although in the wrong case as it
seems?), which will match the hardware prescaler (MCR bit 7).
> Is MCR-bit7 per port, or is it set for the entire chip?
It's per port. The MCR register belongs to the 8 byte register set which
is the same for each port.
> > For a clean solution com(4) should be able to detect a 16654 first,
> > but I don't know how to do it. Are there any differences to detect?
> > In the worst case we have to create a new option, like COM_16654.
>
> In the case of the IOblix, we could always assume 16654. Patrick or
> Mike - what do you recommend regarding detecting a 16654 as compared
> with a 16550?
I have downloaded an Exar ST16650 PDF and I'm quite sure that all chips
of the ST1665x series have an identical register layout (also the same
32-byte FIFO and hardware flow control).
So we only have to fix COM_16650.
> Thanks very much! I'll report back when I've done a few more tests.
Thanks. You may want to try the following patch:
Index: comreg.h
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/comreg.h,v
retrieving revision 1.15
diff -u -r1.15 comreg.h
--- comreg.h 28 Apr 2008 22:00:01 -0000 1.15
+++ comreg.h 27 May 2010 10:22:41 -0000
@@ -98,6 +98,7 @@
#define LCR_5BITS 0x00 /* 5 bits */
/* modem control register */
+#define MCR_PRESCALE 0x80 /* 16650/16950: Baud rate prescaler select */
#define MCR_TCR_TLR 0x40 /* OMAP: enables access to the TCR & TLR regs */
#define MCR_XONENABLE 0x20 /* OMAP XON_EN */
#define MCR_LOOPBACK 0x10 /* Loop test: echos from TX to RX */
Index: com.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/com.c,v
retrieving revision 1.297
diff -u -r1.297 com.c
--- com.c 19 Apr 2010 18:24:26 -0000 1.297
+++ com.c 27 May 2010 10:23:03 -0000
@@ -465,6 +465,8 @@
sc->sc_fifolen = 0;
} else {
SET(sc->sc_hwflags, COM_HW_FLOW);
+ SET(sc->sc_mcr, MCR_PRESCALE);
+ sc->sc_frequency *= 4;
sc->sc_fifolen = 32;
}
} else
@@ -1477,8 +1479,8 @@
KASSERT(sc->sc_type != COM_TYPE_AU1x00);
KASSERT(sc->sc_type != COM_TYPE_16550_NOERS);
/* no EFR on alchemy */
- CSR_WRITE_1(regsp, COM_REG_EFR, sc->sc_efr);
CSR_WRITE_1(regsp, COM_REG_LCR, LCR_EERS);
+ CSR_WRITE_1(regsp, COM_REG_EFR, sc->sc_efr);
}
if (sc->sc_type == COM_TYPE_AU1x00) {
/* alchemy has single separate 16-bit clock divisor register */
--
Frank Wille
Home |
Main Index |
Thread Index |
Old Index