Syba 8-Port Serial Card Unidentified By Kernel
Chris Bergeron
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nicholas Miell
Try echo -n "10b5 9016" > /sys/bus/pci/drivers/serial/new_id and let
Russell King (rmk+s...@arm.linux.org.uk) know if it works (or if it
doesn't, for that matter).
--
Nicholas Miell <nmi...@comcast.net>
Lennart Sorensen
> 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.
Well 8250_pci.c mentions IT8871, so it is probably 8250 style in
interface then.
> 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?
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
Chris Bergeron
> On Fri, Oct 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
>
>> 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.
>>
>
> Well 8250_pci.c mentions IT8871, so it is probably 8250 style in
> interface then.
>
>
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
I/O card (with the other 887x cards being serial/parport PCI cards).
>> 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?
>>
>
> How many serial ports is your kernel configured to use?
>
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
Andrey Panin
> 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.
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 ?
Output of dmesg could be useful too.
--
Andrey Panin | Linux and UNIX system administrator
pa...@donpac.ru | PGP key: wwwkeys.pgp.net
Chris Bergeron
> On 278, 10 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
>
>> 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.
>>
>
> 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 ?
> Output of dmesg could be useful too.
>
>
>
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".
Lennart Sorensen
> 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 & 0x0f)
+ {
+ outb(itmp,ITE8872_INTC[i]+2);
+ break;
+ }
+ }
+}
+
+
+/*
+Integrated Technology Express, Inc.
+IT887x Device Driver
+*/
+static int __devinit
+pci_ite8872_fn(struct pci_dev *pcidev, struct pci_board *board, int enable)
+{
+ int result,ite8872comnum=0,ite8872parportnum=0;
+ short INTA_Addr[8]={ 0x2a0,0x2c0,0x220,0x240,0x1E0,0x200,0x280};
+ u32 j=0,u32Tmp,itmp,ITE8872_COM1,ITE8872_COM2,ITE8872SET=0x64E00000,set60,set78,intc;
+ u32 ite8872_lpt, ite8872_lpthi;
+
+ printk(KERN_INFO "ITE8872 serial init\n");
+ if (!enable) return 0;
+
+ pci_read_config_dword(pcidev, 0x60,&set60);
+ pci_read_config_dword(pcidev, 0x78,&set78);
+
+ for(j=0; j<7; j++)
+ if(check_region(INTA_Addr[j], 0x8) >=0){
+ pci_write_config_dword(pcidev, 0x60,0xE7000000|INTA_Addr[j]);
+ pci_write_config_dword(pcidev, 0x78,0x00000000|INTA_Addr[j]);
+ itmp = inb( INTA_Addr[j]);
+ if( itmp != 0xFF ) break;
+ }
+
+ if( j>=7 ){
+ printk(KERN_INFO "ITE8872 INTA cannot find.\n");
+ return 0;
+ }
+
+ itmp = INTA_Addr[j];
+ u32Tmp = inb(itmp+0x18);
+ u32Tmp &= 0x0F;
+ intc= INTA_Addr[j];
+ switch(u32Tmp){
+ case 0x2:
+ printk(KERN_INFO "ITE887x: ITE8871 found , Parallel*1 \n");
+ ITE8872SET = 0x64200000;
+ ite8872parportnum=1;
+ request_region(intc,0x8,"ite8871");
+ break;
+ case 0xA:
+ printk(KERN_INFO "ITE887x: ITE8875 found , Parallel*1 \n");
+ ITE8872SET = 0x64200000;
+ ite8872parportnum=1;
+ request_region(intc,0x8,"ite8875");
+ break;
+ case 0xE:
+ printk(KERN_INFO "ITE887x: ITE8872 found , Serial *2 , Parallel*1 \n");
+ ite8872comnum = 2;
+ ite8872parportnum=1;
+ ITE8872SET=0x64E00000;
+ request_region(intc,0x8,"ite8872");
+ break;
+ case 0x6:
+ printk(KERN_INFO "ITE887x: ITE8873 found , Serial *1 \n");
+ ite8872comnum = 1;
+ ITE8872SET=0x64800000;
+ request_region(intc,0x8,"ite8873");
+ break;
+ case 0x8:
+ printk(KERN_INFO "ITE887x: ITE8874 found , Serial *2 \n");
+ ite8872comnum = 2;
+ ITE8872SET=0x64C00000;
+ request_region(intc,0x8,"ite8874");
+ break;
+ default:
+ printk(KERN_INFO "ITE887x: unknow ITE887x \n");
+ printk(KERN_INFO "ITE887x: please mail lspci -nvv output to ted...@ite.com.tw\n");
+ pci_write_config_dword(pcidev, 0x60,set60);
+ pci_write_config_dword(pcidev, 0x78,set78);
+ return 0;
+ break;
+ }
+
+// pci_read_config_dword(pcidev, 0x3c,&ITE8872_IRQ[ITEBOARDNUMBER]);
+ ITE8872_IRQ[ITEBOARDNUMBER]=pcidev->irq;
+
+ printk(KERN_INFO "ITE887X_IRQ : %d \n", ITE8872_IRQ[ITEBOARDNUMBER]);
+ if (ite8872comnum>=1) {
+ result = request_irq(ITE8872_IRQ[ITEBOARDNUMBER],ite8872_requestirq,SA_SHIRQ,"ite8872",&ITE8872_IRQ[ITEBOARDNUMBER]);
+ if(result){
+ printk(KERN_INFO "ITE887x: can't get assign irq :%x \n",ITE8872_IRQ[ITEBOARDNUMBER]);
+ return 0;
+ }
+ }
+
+
+ //INTC
+ pci_read_config_dword( pcidev, 0x10, &ITE8872_INTC[ITEBOARDNUMBER]);
+ ITE8872_INTC[ITEBOARDNUMBER] &= 0x0000FF00;
+ pci_write_config_dword( pcidev, 0x60, 0xE5000000|ITE8872_INTC[ITEBOARDNUMBER] );
+ pci_write_config_dword( pcidev, 0x78, ITE8872_INTC[ITEBOARDNUMBER] );
+
+ if (ite8872parportnum>=1)
+ {
+ //parport
+ pci_read_config_dword (pcidev, 0x1c, &ite8872_lpt);
+ ite8872_lpt &= 0x0000ff00;
+ pci_read_config_dword (pcidev, 0x20, &ite8872_lpthi);
+ ite8872_lpthi &= 0x0000ff00;
+ pci_write_config_dword (pcidev, 0x6c, 0xe3000000 | ite8872_lpt);
+ pci_write_config_dword (pcidev, 0x70, 0xe3000000 | ite8872_lpthi);
+ pci_write_config_dword (pcidev, 0x80, (ite8872_lpthi<<16) | ite8872_lpt);
+ // SET SPP&EPP , Parallel Port NO DMA , Enable All Function
+ // SET Parallel IRQ
+ printk (KERN_INFO "ITE887x: The PARALLEL I/O port is 0x%x.\n",
+ ite8872_lpt);
+ printk (KERN_INFO "ITE887x: The PARALLEL I/O porthi is 0x%x.\n",
+ ite8872_lpthi);
+ }
+
+ if (ite8872comnum>=1){
+ //COM1
+ pci_read_config_dword( pcidev, 0x14,&ITE8872_COM1);
+ ITE8872_COM1 &= 0x0000FF00;
+ pci_write_config_dword( pcidev, 0x64, 0xE3000000|ITE8872_COM1);
+
+ //COM2
+ if(ite8872comnum == 2){
+ pci_read_config_dword( pcidev, 0x18,&ITE8872_COM2);
+ ITE8872_COM2 &= 0x0000FF00;
+ pci_write_config_dword( pcidev, 0x68, 0xE3000000|ITE8872_COM2);
+ }
+ else ITE8872_COM2 = 0;
+
+ pci_write_config_dword( pcidev, 0x7C, (ITE8872_COM2<<16)|(ITE8872_COM1) );
+ }
+
+ // 9C write enable UART , IRQ Function
+ pci_write_config_dword( pcidev, 0x9c,ITE8872SET|(0x11111*ITE8872_IRQ[ITEBOARDNUMBER]));
+ // Add next interface
+ ITEBOARDNUMBER++;
+ return 0;
+
+}
+
+
/* Added for EKF Intel i960 serial boards */
static int __devinit
pci_inteli960ni_fn(struct pci_dev *dev,
@@ -4348,6 +4512,9 @@
#ifdef CONFIG_DDB5074
pbn_nec_nile4,
#endif
+#if 1
+ pbn_ite_8872,
+#endif
#if 0
pbn_dci_pccom8,
#endif
@@ -4444,6 +4611,10 @@
{ SPCI_FL_BASE0, 1, 520833, /* pbn_nec_nile4 */
64, 3, NULL, 0x300 },
#endif
+#if 1 /* PCI_DEVCE_ID_ITE_8872 */
+ {SPCI_FL_BASE1| SPCI_FL_BASE_TABLE, 2, 115200,
+ 0, 0, pci_ite8872_fn, 0},
+#endif
#if 0 /* PCI_DEVICE_ID_DCI_PCCOM8 ? */ /* pbn_dci_pccom8 */
{ SPCI_FL_BASE3, 8, 115200, 8 },
#endif
@@ -4906,7 +5077,11 @@
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_nec_nile4 },
#endif
-
+#if 1 /* ITE 8872 Serial Simple Board */
+ { PCI_VENDOR_ID_ITE, PCI_DEVICE_ID_ITE_8872,
+ PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ pbn_ite_8872 },
+#endif
#if 0 /* PCI_DEVICE_ID_DCI_PCCOM8 ? */
{ PCI_VENDOR_ID_DCI, PCI_DEVICE_ID_DCI_PCCOM8,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
--- drivers/parport/parport_pc.c 2002-11-28 18:53:14.000000000 -0500
+++ /tmp/parport_pc_20.c 2006-11-23 03:17:24.000000000 -0500
@@ -253,6 +253,9 @@
return !(r & 0x01);
}
+
+
+
/*
* Access functions.
*
@@ -2440,82 +2443,29 @@
static int __devinit sio_ite_8872_probe (struct pci_dev *pdev, int autoirq,
int autodma)
{
- short inta_addr[6] = { 0x2A0, 0x2C0, 0x220, 0x240, 0x1E0 };
- u32 ite8872set;
- u32 ite8872_lpt, ite8872_lpthi;
- u8 ite8872_irq, type;
+ u32 ite8872_lpt, ite8872_lpthi,test;
+ u8 ITE8872_IRQ;
int irq;
- int i;
- DPRINTK (KERN_DEBUG "sio_ite_8872_probe()\n");
+ pci_read_config_dword (pdev, 0x6c, &test);
+ if (test ==0 ) return 0;
- // make sure which one chip
- for(i = 0; i < 5; i++) {
- if (check_region (inta_addr[i], 0x8) >= 0) {
- int test;
- pci_write_config_dword (pdev, 0x60,
- 0xe7000000 | inta_addr[i]);
- pci_write_config_dword (pdev, 0x78,
- 0x00000000 | inta_addr[i]);
- test = inb (inta_addr[i]);
- if (test != 0xff) break;
- }
- }
- if(i >= 5) {
- printk (KERN_INFO "parport_pc: cannot find ITE8872 INTA\n");
- return 0;
- }
-
- type = inb (inta_addr[i] + 0x18);
- type &= 0x0f;
-
- switch (type) {
- case 0x2:
- printk (KERN_INFO "parport_pc: ITE8871 found (1P)\n");
- ite8872set = 0x64200000;
- break;
- case 0xa:
- printk (KERN_INFO "parport_pc: ITE8875 found (1P)\n");
- ite8872set = 0x64200000;
- break;
- case 0xe:
- printk (KERN_INFO "parport_pc: ITE8872 found (2S1P)\n");
- ite8872set = 0x64e00000;
- break;
- case 0x6:
- printk (KERN_INFO "parport_pc: ITE8873 found (1S)\n");
- return 0;
- case 0x8:
- DPRINTK (KERN_DEBUG "parport_pc: ITE8874 found (2S)\n");
- return 0;
- default:
- printk (KERN_INFO "parport_pc: unknown ITE887x\n");
- printk (KERN_INFO "parport_pc: please mail 'lspci -nvv' "
- "output to Rich...@ite.com.tw\n");
- return 0;
- }
-
- pci_read_config_byte (pdev, 0x3c, &ite8872_irq);
+// pci_read_config_byte (pdev, 0x3c, &ITE8872_IRQ);
+ ITE8872_IRQ=pdev->irq;
pci_read_config_dword (pdev, 0x1c, &ite8872_lpt);
ite8872_lpt &= 0x0000ff00;
pci_read_config_dword (pdev, 0x20, &ite8872_lpthi);
ite8872_lpthi &= 0x0000ff00;
- pci_write_config_dword (pdev, 0x6c, 0xe3000000 | ite8872_lpt);
- pci_write_config_dword (pdev, 0x70, 0xe3000000 | ite8872_lpthi);
- pci_write_config_dword (pdev, 0x80, (ite8872_lpthi<<16) | ite8872_lpt);
- // SET SPP&EPP , Parallel Port NO DMA , Enable All Function
- // SET Parallel IRQ
- pci_write_config_dword (pdev, 0x9c,
- ite8872set | (ite8872_irq * 0x11111));
-
- DPRINTK (KERN_DEBUG "ITE887x: The IRQ is %d.\n", ite8872_irq);
- DPRINTK (KERN_DEBUG "ITE887x: The PARALLEL I/O port is 0x%x.\n",
+
+ printk (KERN_INFO "ITE887x: The IRQ is %d.\n", ITE8872_IRQ);
+ printk (KERN_INFO "ITE887x: The PARALLEL I/O port is 0x%x.\n",
ite8872_lpt);
- DPRINTK (KERN_DEBUG "ITE887x: The PARALLEL I/O porthi is 0x%x.\n",
+ printk (KERN_INFO "ITE887x: The PARALLEL I/O porthi is 0x%x.\n",
ite8872_lpthi);
+
/* Let the user (or defaults) steer us away from interrupts */
- irq = ite8872_irq;
+ irq = ITE8872_IRQ;
if (autoirq != PARPORT_IRQ_AUTO)
irq = PARPORT_IRQ_NONE;
@@ -2525,7 +2475,7 @@
"parport_pc: ITE 8872 parallel port: io=0x%X",
ite8872_lpt);
if (irq != PARPORT_IRQ_NONE)
- printk (", irq=%d", irq);
+ printk (KERN_INFO " irq=%d", irq);
printk ("\n");
return 1;
}
--
Len Sorensen
Chris Bergeron
> On Thu, Oct 11, 2007 at 01:02:12PM -0400, Chris Bergeron wrote:
>
>> 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".
>>
>
> 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.
>
that code to see if it includes something to drive the card then, for
starters.
-- Chris
Andrey Panin
> Andrey Panin wrote:
>> On 278, 10 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
>>
>>> 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.
>>>
>>
>> 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 ?
>> Output of dmesg could be useful too.
>>
>>
>>
> 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
Can you try an attached patch ? I hope it should at least detect UARTs on
your board. Be ready that baudrate could be wrong, because we do not know
what frequency is used to clock these UARTs.
> 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".
--
Chris Bergeron
> On 284, 10 11, 2007 at 01:02:12PM -0400, Chris Bergeron wrote:
>
>> Andrey Panin wrote:
>>
>>> On 278, 10 05, 2007 at 05:31:05PM -0400, Chris Bergeron wrote:
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> 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 ?
>>> Output of dmesg could be useful too.
>>>
>>>
>> 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
>>
>
> Can you try an attached patch ? I hope it should at least detect UARTs on
> your board. Be ready that baudrate could be wrong, because we do not know
> what frequency is used to clock these UARTs.
>
>
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
Andrey Panin
This message apearred after firewire driver initialization and firewire chip
shares IRQ with serial card. It's hard to say who is guilty here :)
> 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.
Is it possible to connect two ports and run getty on one port and minicom on
another ? We should check that UARTs are really working.
> 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
--
Chris Bergeron
>
> Is it possible to connect two ports and run getty on one port and minicom on
> another ? We should check that UARTs are really working.
>
>
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.
Andrey Panin
> Andrey Panin wrote:
>>
>> Is it possible to connect two ports and run getty on one port and minicom
>> on
>> another ? We should check that UARTs are really working.
>>
>>
> 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.
Oh crap... I missed this fscking "Disabling IRQ #17" line in your dmesg.
Can you try with firewire controller disabled somehow ?
Chris Bergeron
> On 290, 10 17, 2007 at 06:16:58 -0400, Chris Bergeron wrote:
>
>> Andrey Panin wrote:
>>
>>> Is it possible to connect two ports and run getty on one port and minicom
>>> on
>>> another ? We should check that UARTs are really working.
>>>
>>>
>>>
>> 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.
>>
>
> Oh crap... I missed this fscking "Disabling IRQ #17" line in your dmesg.
> Can you try with firewire controller disabled somehow ?
>
>
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
ky...@xtechgear.com
breakout cable. It is identified as such on my machine:
01:02.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 9
Region 0: I/O ports at b800 [disabled] [size=64]
Region 1: I/O ports at b400 [disabled] [size=16]
Region 2: I/O ports at b000 [disabled] [size=16]
Region 3: Memory at ff8fe000 (32-bit, non-prefetchable) [disabled]
[size=4K]
Region 4: Memory at ff8fd000 (32-bit, non-prefetchable) [disabled]
[size=4K]
Region 5: Memory at ff8fc000 (32-bit, non-prefetchable) [disabled]
[size=4K]
There was also a driver cd included with my card, and I've placed the
drivers at:
http://www.sasseriansection.com/media/files/it8871.tar.gz
I have not been able to get the drivers to install properly into my 2.6.18
kernel though.
Looking at the files and whatnot, it does seem that the suspicions posted
here were correct. That the card is ran via a parallel port, and through
this parallel port the uarts are accessed. The drivers seem to basically be
a modified parport_pc module. The drivers that came with the card are for a
2.4 kernel though.
I also found a couple references to work on some kernel modules at
http://lkml.org/lkml/2007/8/10/404 regarding adding 8871 support, but
haven't been able to do much with it.
Hope this information is helpful to someone, and if possible please CC me on
any additional discussions regarding this card.
-------------
Kyle Sasser
Andrey Panin
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 ?
Lennart Sorensen
> 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 ?
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
Chris Bergeron
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
Andrey Panin
> On Mon, Oct 22, 2007 at 07:33:23PM +0400, Andrey Panin wrote:
> > 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 ?
>
> 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.
I dont think so. IT887x has builtin interrupt controller which multiplexes
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
triggered settings.
> 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.
--
Bjorn Helgaas
> On 295, 10 22, 2007 at 01:14:14 -0400, Chris Bergeron wrote:
> > Andrey Panin wrote:
> >> On 291, 10 18, 2007 at 01:00:06 -0400, Chris Bergeron wrote:
> >> 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 point me to any of those IT887x docs? I haven't been able
to dig any up myself.
> Can you test an attached patch against 2.6.24-rc1 ?
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 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
--
Bjorn Helgaas
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); /* internal edge (unused) */
+
+ outb(0x00, intc_base + ITE_887x_ITR0); /* clear SW-generated ints */
+ outb(0x00, intc_base + ITE_887x_ITR1);
+ outb(0x00, intc_base + ITE_887x_ITR2);
+
+ outb(0x00, intc_base + ITE_887x_IRR0); /* clear any pending ints */
+ outb(0x00, intc_base + ITE_887x_IRR1);
+ outb(0x00, intc_base + ITE_887x_IRR2);
+
+ outb(0x00, intc_base + ITE_887x_IMR0); /* unmask external IRQ 0-7 */
+
+ return 8;
+}
+
static int
pci_default_setup(struct serial_private *priv, struct pciserial_board *board,
struct uart_port *port, int idx)
@@ -835,6 +884,18 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.exit = __devexit_p(pci_ite887x_exit),
},
/*
+ * Syba
+ */
+ {
+ .vendor = PCI_VENDOR_ID_PLX,
+ .device = 0x9016,
+ .subvendor = 0x544e,
+ .subdevice = 0x0008,
+ .init = pci_syba_ite887x_init,
+ .setup = pci_default_setup,
+ /* .exit = __devexit_p(pci_ite887x_exit), */
+ },
+ /*
* Panacom
*/
{
@@ -1085,6 +1146,8 @@ enum pci_board_num_t {
pbn_b0_5_115200,
pbn_b0_8_115200,
+ pbn_b0_8_460800,
+
pbn_b0_1_921600,
pbn_b0_2_921600,
pbn_b0_4_921600,
@@ -1226,6 +1289,12 @@ static struct pciserial_board pci_boards[] __devinitdata = {
.base_baud = 115200,
.uart_offset = 8,
},
+ [pbn_b0_8_460800] = {
+ .flags = FL_BASE0,
+ .num_ports = 8,
+ .base_baud = 460800,
+ .uart_offset = 8,
+ },
[pbn_b0_1_921600] = {
.flags = FL_BASE0,
.num_ports = 1,
@@ -2581,6 +2650,11 @@ static struct pci_device_id serial_pci_tbl[] = {
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b3_8_115200 },
+ /* Syba PCI8871-PR8 8-port serial card */
+ { PCI_VENDOR_ID_PLX, 0x9016,
+ 0x544e, 0x0008, 0, 0,
+ pbn_b0_8_460800 },
+
/*
* Exar Corp. XR17C15[248] Dual/Quad/Octal UART
*/
Bjorn Helgaas
an editing mistake left the UART interrupts enabled. Can you try
the patch below instead?
If this doesn't work, I'll have to add some debug and try to figure
out what is happening, but let's try the easy thing first.
Bjorn
diff --git a/drivers/serial/8250_pci.c b/drivers/serial/8250_pci.c
index c2f2393..dc59a1f 100644
+ outb(0xff, intc_base + ITE_887x_IMR0); /* mask external IRQ 0-7 */