login
Search
Hello all,
I've just installed a multiport serial card released by an outfit called
Syba. This is an 8 port serial-only card with an Octopus style breakout
cable. The main chipset on it is an ITE IT8871F.
I've got two questions on this: Is there a driver I should try force
loading on it (and if so, what options to use)? and is there any useful
testing I can do to report back to the LKML on this card?
Thanks for your time, diagnostic output follows.
-- Chris
The following comes up from an "lspci -vv"
01:06.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev
01) (prog-if 02 [16550])
Subsystem: Unknown device 544e:0008
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at a000 [size=64]
Region 1: I/O ports at a400 [size=16]
Region 2: I/O ports at a800 [size=16]
Region 3: Memory at f5000000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at f5001000 (32-bit, non-prefetchable) [size=4K]
Region 5: Memory at f5002000 (32-bit, non-prefetchable) [size=4K]
and "lshw" outputs:
*-communication UNCLAIMED
description: Serial controller
product: PLX Technology, Inc.
vendor: PLX Technology, Inc.
physical id: 6
bus info: pci@0000:01:06.0
version: 01
width: 32 bits
clock: 33MHz
capabilities: 16550
configuration: latency=0
-
Try echo -n "10b5 9016" > /sys/bus/pci/drivers/serial/new_id and let Russell King (rmk+serial@arm.linux.org.uk) know if it works (or if it doesn't, for that matter). -- Nicholas Miell <nmiell@comcast.net> -
Well 8250_pci.c mentions IT8871, so it is probably 8250 style in How many serial ports is your kernel configured to use? CONFIG_SERIAL_8250_NR_UARTS=16 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 That is from my Debian system's kernel, and it won't activate more than 4 ports automatically. It will allow up to 16 to be activated though. I don't remember what the boot command is to override those values to make the system look for more ports. -- Len Sorensen -
That's what I had thought too after a quick LKML search. Doing a bit more research (I'm starting to think the IT8871F on the chip is misleading) it looks like that support is for a single parallel multi The kernel I'm using has 16 for both the NR_UARTS and RUNTIME_UARTS (these machines generally have a minimum of 4 ports). dmesg doesn't show the kernel as recognizing the card and only ttyS0 and ttyS1 (the two onboard ports) show up on boot. -- Chris -
Are you sure ? IIRC IT887x are PCI-ISA bridges with additional periphery and your lspci shows PLX chip. Can you send complete lspci -vv output ? --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
I'm sure that's what it says on the largest chip on the PCI card. It could be that the other two chips are more relevant... the numbers from them are included below. I've posted up a quick text only page with the diagnostic information from the system (full dmesg, lspci, etc) plus links to pictures of the board (since others might see something important that I'm not aware of). You can access that at http://pcburn.com/files/Syba_serial_controller/index.html One chip has "ITE IT8871F 0641-AYS ZF1M04L" written on it, and the other two have a stylized celtic knot looking "T" followed by "TG16C554CJG FTA6M-001 0620-B". -
Well TG16C554 sounds awfully similar to 16550 which is a common UART type. Perhaps 554 indicates it is 4 16550s in one chip. There are two of those chips in one of the pictures. Here is a data sheet for it: http://www.twistsemi.com/downloads/TG16C554V1.5.pdf It is in fact a quad UART chip. It appears to have 4 chip select lines to pick between the 4 UARTS, 3 address lines to access the 8 16550 registers, and 8 data lines to read and write those registers as well as a pair of read and write enable lines. They are NOT PCI chips, so quite likely the IT8871 is there as a PCI to parallel convertor and then the parallel interface connects to the UARTs. No idea where the IRQ line from the chips would connect to (one of the parallel port signals that generates an IRQ?) The 8 small chips are probably RS232 level convertors. The 8871 is a single PCI parallel port, so certainly somehow they are controlling the two serial to parallel chips through that pci parallel port. I included the diff of the files you had on your web page and the originals founds in 2.4.20 (which is what they claim they replace). I can't really tell if there is any code there to deal with their quad uart chip or not. --- drivers/char/serial.c 2002-11-28 18:53:12.000000000 -0500 +++ /tmp/serial_20.c 2006-11-23 03:17:24.000000000 -0500 @@ -257,6 +257,13 @@ static struct timer_list serial_timer; +//struct pci_dev *pcidev = NULL; +// ITE8872 ITE8872 +u32 ITE8872_INTC[8]; +int ITEBOARDNUMBER=0; +u8 ITE8872_IRQ[8]; + + /* serial subtype definitions */ #ifndef SERIAL_TYPE_NORMAL #define SERIAL_TYPE_NORMAL 1 @@ -4165,6 +4172,163 @@ } EXPORT_SYMBOL(pci_siig20x_fn); +void ite8872_requestirq(int irq,void *dev_id,struct pt_regs *regs){ + u8 itmp; + int i=0; + /* measure which INTC went to control */ + for(i=0;i<8;i++) + if(irq == ITE8872_IRQ[i]) + { + /* clean ITE8872 interrupt */ + itmp = inb(ITE8872_INTC[i]+2); + if(itmp & ...
I'll see if I can compile up the appropriate kernel and test it with that code to see if it includes something to drive the card then, for starters. -- Chris -
--aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Can you try an attached patch ? I hope it should at least detect UARTs on= =20 your board. Be ready that baudrate could be wrong, because we do not know --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-syba Content-Transfer-Encoding: quoted-printable diff -urdpNX /usr/share/dontdiff linux-2.6.23.vanilla/drivers/serial/8250_p= ci.c linux-2.6.23/drivers/serial/8250_pci.c --- linux-2.6.23.vanilla/drivers/serial/8250_pci.c 2007-10-12 14:20:44.0000= 00000 +0400 +++ linux-2.6.23/drivers/serial/8250_pci.c 2007-10-12 14:07:08.000000000 +0= 400 @@ -1036,6 +1036,7 @@ enum pci_board_num_t { pbn_b0_2_115200, pbn_b0_4_115200, pbn_b0_5_115200, + pbn_b0_8_115200, =20 pbn_b0_1_921600, pbn_b0_2_921600, @@ -1172,6 +1173,12 @@ static struct pciserial_board pci_boards .base_baud =3D 115200, .uart_offset =3D 8, }, + [pbn_b0_8_115200] =3D { + .flags =3D FL_BASE0, + .num_ports =3D 8, + .base_baud =3D 115200, + .uart_offset =3D 8, + }, =20 [pbn_b0_1_921600] =3D { .flags =3D FL_BASE0, @@ -2520,6 +2527,11 @@ static struct pci_device_id serial_pci_t PCI_ANY_ID, PCI_ANY_ID, 0, 0, pbn_b3_8_115200 }, =20 + /* Syba PCI8871-PR8 8-port serial card */ + { PCI_VENDOR_ID_PLX, 0x9016, + 0x544e, 0x0008, 0, 0, + pbn_b0_8_115200 }, + /* * Exar Corp. XR17C15[248] Dual/Quad/Octal UART */ --aM3YZ0Iwxop3KEKx--
Alright,finally had another machine to try the attached patch. I get an odd error regarding IRQ 17: "irq 17: nobody cared (try booting with the "irqpoll" option)" along with a long error message (but the kernel continues to load). Aside from that the ports now allow me to run a getty on them and the DTR line lights up on my serial tester (as it does with a working port) but the device on the other end doesn't function. I've updated the web page with lspci -vv and dmesg output. I can also post it here if that's desirable, just figured I'd save everyone the inbox flooding :). -- Chris -
This message apearred after firewire driver initialization and firewire chip Is it possible to connect two ports and run getty on one port and minicom on --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
I used the on-board serial port as a known working control (after getting it to work with the other onboard serial port) to try and connect over to one of the Syba card ports (using Cutecom & getty). The lines light up, but there's nothing getting sent from the 8-port as far as I can see. The onboard port works as I'd expect, the Syba (running getty identically from inittab) doesn't. -- Chris -
Oh crap... I missed this fscking "Disabling IRQ #17" line in your dmesg. Can you try with firewire controller disabled somehow ? --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Ah, I forgot to make note of that. I did actually turn off Firewire in the BIOS. Assuming that worked (and it looks like it did) the following section probably contains the relevant bits. Still getting the IRQ 17 error. -- Chris PCI: Setting latency timer of device 0000:00:05.0 to 64 NET: Registered protocol family 17 eth0: no IPv6 routers present irq 17: nobody cared (try booting with the "irqpoll" option) [<c0104f45>] show_trace_log_lvl+0x1a/0x2f [<c0105939>] show_trace+0x12/0x14 [<c0105951>] dump_stack+0x16/0x18 [<c0152f90>] __report_bad_irq+0x39/0x79 [<c01531af>] note_interrupt+0x1df/0x218 [<c0153754>] handle_fasteoi_irq+0x91/0xb6 [<c0105fef>] do_IRQ+0x7c/0x95 [<c0104946>] common_interrupt+0x2e/0x34 [<c010233a>] cpu_idle+0x1c/0xc2 [<c02deed9>] rest_init+0x4d/0x4f [<c03e7979>] start_kernel+0x32a/0x332 [<00000000>] 0x0 ======================= handlers: [<c023ecae>] (serial8250_interrupt+0x0/0x115) Disabling IRQ #17 hda: DMA timeout retry full dmesg output at http://pcburn.com/files/Syba_serial_controller/dmesg_with_1394_disabled.txt -
xt So the card probably generates screaming interrupt... that's bad. I found some docs for IT887x chips, according to these docs IT887x have simple interrupt controller inside. Further investigation is needed. Can you post output of lspci -xxx ? --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Is it possible they put a chip on to generate a PCI interrupt on perhaps PCIB on the slot from the serial chips directly, so that they didn't have to turn interrupts from the serial chips into a signal that forces the parallel port to generate an interrupt? After all that would reduce latency, and if you use PCIA for the parallel port, PCIB for the first serial chip and PCIC for the second, you might get a much more efficient design, although the driver would have to register all those IRQs. What IRQ is each PCI device in that system using right now? perhaps we could figure out what irq 17 would be on that PCI slot. -- Len Sorensen -
I dont think so. IT887x has builtin interrupt controller which multiplexes= =20 16 external IRQ pins with IRQs from builtin devices (parallel port, UARTs and GPIO) into single INTA# line. IT887x also contains 8-bit ISA-like bus and 16 chip select lines and it's all you need to glue UARTs to PCI bus. I suspect that it's interrupt controller problem, probably edge/level --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net
Full output at http://pcburn.com/files/Syba_serial_controller/lspci_xxx.out. The relevant part for the Syba card is probably: 01:08.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev 01) 00: b5 10 16 90 07 00 80 02 01 02 00 07 00 00 00 00 10: 01 a4 00 00 01 a8 00 00 01 ac 00 00 00 00 00 f5 20: 00 10 00 f5 00 20 00 f5 00 00 00 00 4e 54 08 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00 40: 3f 3f 08 00 00 8c 20 8b 45 54 55 45 00 00 10 d2 50: 01 01 71 03 01 03 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 03 00 06 f8 03 f8 02 80: 78 03 78 07 00 08 00 07 00 01 20 01 40 01 60 01 90: 00 00 00 00 00 00 00 00 00 00 00 00 70 43 25 64 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Chris -
--CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Can you test an attached patch against 2.6.24-rc1 ? --=20 Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-syba-2 Content-Transfer-Encoding: quoted-printable diff -urdpNX dontdiff linux-2.6.24.vanilla/drivers/serial/8250_pci.c linux-= 2.6.24/drivers/serial/8250_pci.c --- linux-2.6.24.vanilla/drivers/serial/8250_pci.c 2007-10-28 13:00:14.0000= 00000 +0300 +++ linux-2.6.24/drivers/serial/8250_pci.c 2007-10-28 18:15:12.000000000 +0= 300 @@ -610,45 +610,49 @@ static int pci_netmos_init(struct pci_de /* enable IO_Space bit */ #define ITE_887x_POSIO_ENABLE (1 << 31) =20 -static int pci_ite887x_init(struct pci_dev *dev) +static int pci_ite_887x_allocate_io(struct pci_dev *dev) { - /* inta_addr are the configuration addresses of the ITE */ - static const short inta_addr[] =3D { 0x2a0, 0x2c0, 0x220, 0x240, 0x1e0, - 0x200, 0x280, 0 }; - int ret, i, type; - struct resource *iobase =3D NULL; - u32 miscr, uartbar, ioport; + static const short inta_addr[] =3D { + 0x2a0, 0x2c0, 0x220, 0x240, 0x1e0, 0x200, 0x280, 0 + }; + int ret, i; =20 - /* search for the base-ioport */ - i =3D 0; - while (inta_addr[i] && iobase =3D=3D NULL) { - iobase =3D request_region(inta_addr[i], ITE_887x_IOSIZE, - "ite887x"); - if (iobase !=3D NULL) { + for (i =3D 0; i < ARRAY_SIZE(inta_addr); i++) { + int iobase =3D inta_addr[i]; + + if (request_region(iobase, ITE_887x_IOSIZE, "ite887x")) { /* write POSIO0R - speed | size | ioport */ pci_write_config_dword(dev, ITE_887x_POSIO0, ITE_887x_POSIO_ENABLE | ITE_887x_POSIO_SPEED | - ITE_887x_POSIO_IOSIZE_32 | inta_addr[i]); + ITE_887x_POSIO_IOSIZE_32 | iobase); + /* write INTCBAR - ioport ...
Can you point me to any of those IT887x docs? I haven't been able I tested basically the same patch against a current upstream tree, and the syba ports don't work, even with "irqpoll". Here's the discovery: Serial: 8250/16550 driver16 ports, IRQ sharing enabled <FF>serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A pnp: the driver 'serial' has been registered 00:10: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial 00:10: driver attached 00:11: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A serial 00:11: driver attached serial 0000:00:01.0: check 0x2a0 serial 0000:00:01.0: got 0x0 serial 0000:00:01.0: syba at 0x000002a0 serial 0000:00:01.0: ite887x: io base at 0x2a0 serial 0000:00:01.0: ite887x: IRR0=00 IMR0=00 IER0=00 serial 0000:00:01.0: ite887x: IRR1=00 IMR1=00 IER1=00 serial 0000:00:01.0: ite887x: IRR2=00 IMR2=00 IER2=00 0000:00:01.0: ttyS4 at I/O 0x1000 (irq = 16) is a 16550A 0000:00:01.0: ttyS5 at I/O 0x1008 (irq = 16) is a 16550A 0000:00:01.0: ttyS6 at I/O 0x1010 (irq = 16) is a 16550A 0000:00:01.0: ttyS7 at I/O 0x1018 (irq = 16) is a 16550A 0000:00:01.0: ttyS8 at I/O 0x1020 (irq = 16) is a 16550A 0000:00:01.0: ttyS9 at I/O 0x1028 (irq = 16) is a 16550A 0000:00:01.0: ttyS10 at I/O 0x1030 (irq = 16) is a 16550A 0000:00:01.0: ttyS11 at I/O 0x1038 (irq = 16) is a 16550A The entire dmesg log is at http://helgaas.com/tmp/sybase.txt The patch I tested is at http://helgaas.com/tmp/sybase.patch Here's the "lspci -xxx" output: 00:01.0 Serial controller: PLX Technology, Inc. Unknown device 9016 (rev 01) 00: b5 10 16 90 03 01 80 02 01 02 00 07 00 00 00 00 10: 01 10 00 00 d1 10 00 00 c1 10 00 00 00 30 24 e8 20: 00 20 24 e8 00 10 24 e8 00 00 00 00 4e 54 08 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00 40: 3f 3f 08 00 00 8c 20 8b 45 54 55 45 00 00 10 d2 50: 01 01 71 03 01 03 00 00 00 00 00 00 00 00 00 00 60: a0 02 00 e5 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 a0 02 00 00 f8 03 f8 ...
Here's a 2.6.27-rc3 patch that works for me.
I only have one card, so I can't test this with multiple cards.
I don't know whether there's any way the INTC_GPIO base addresses
would get programmed to non-conflicting values. My card comes
up with the INTC_GPIO area at I/O ports 0x0300-0x031f, but that
might be a default that's just hardwired into the card.
It looks like we could allocate this region when we claim the
device, which should let us support multiple cards, but I haven't
tried this.
If anybody tries this out, let me know how it works.
Bjorn
diff --git a/drivers/serial/8250_pci.c b/drivers/serial/8250_pci.c
index c2f2393..d442ddb 100644
--- a/drivers/serial/8250_pci.c
+++ b/drivers/serial/8250_pci.c
@@ -737,6 +737,55 @@ static void __devexit pci_ite887x_exit(struct pci_dev *dev)
release_region(ioport, ITE_887x_IOSIZE);
}
+#define ITE_887x_IRR0 0
+#define ITE_887x_IRR1 1
+#define ITE_887x_IRR2 2
+#define ITE_887x_IMR0 4
+#define ITE_887x_IMR1 5
+#define ITE_887x_IMR2 6
+#define ITE_887x_IER0 8
+#define ITE_887x_IER1 9
+#define ITE_887x_IER2 10
+#define ITE_887x_ITR0 12
+#define ITE_887x_ITR1 13
+#define ITE_887x_ITR2 14
+
+static int pci_syba_ite887x_init(struct pci_dev *dev)
+{
+ u32 ddma_intc_base, intc_base;
+ struct resource *iobase;
+
+ pci_read_config_dword(dev, ITE_887x_INTCBAR, &ddma_intc_base);
+ intc_base = ddma_intc_base & 0xffff;
+
+ iobase = request_region(intc_base, ITE_887x_IOSIZE, "ite887x");
+ if (!iobase) {
+ dev_err(&dev->dev, "can't request INTC_Base at 0x%x\n",
+ intc_base);
+ return -ENODEV;
+ }
+
+ outb(0x00, intc_base + ITE_887x_IMR0); /* mask external IRQ 0-7 */
+ outb(0xff, intc_base + ITE_887x_IMR1); /* mask external IRQ 8-15 */
+ outb(0xff, intc_base + ITE_887x_IMR2); /* mask internal interrupts */
+
+ outb(0xff, intc_base + ITE_887x_IER0); /* IRQ 0-7 level-triggered */
+ outb(0x00, intc_base + ITE_887x_IER1); /* IRQ 8-15 edge (unused) */
+ outb(0x00, intc_base + ITE_887x_IER2); /* ...
