Date: Tue, 23 Nov 2004 00:36:26 -0500 (EST) From: Paul Sandys <myj@nyct.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-stable@FreeBSD.org Subject: Re: SIIG cards and puc Message-ID: <20041123002829.R70859@bsd3.nyct.net> In-Reply-To: <20041122.173636.102807556.imp@bsdimp.com> References: <20041120084456.GU57546@funkthat.com> <20041122113525.G31812@bsd3.nyct.net> <20041122.173636.102807556.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
What was happening at the beginning, it was mangling data coming into the
computer and 'cu -l /dev/cuaa5' was taking up 100% CPU in interrupt. It was only
showing first 31 characters of input, then it froze until I hit Enter couple
times and such. My original idea was "this thing claims to have 64 FIFO and it
only shows 31 charaters", so I found the COM_FIFOSIZE option. Setting it didn't
really help. Then I tried it together with setting the "0x00001 shared IRQs" -
from sio manpage. That didn't help either. So I went through the sio.c code and
found that the "COM_MULTIPORT" option is widely used in the interrupt routine,
so I tried setting it - that card has only one interrupt, so it must be shared -
right ?
At that point, I got it to work, so I was happy. All of this was done on
4.10-STABLE machine.
puc0: <SIIG Cyber Serial Dual PCI 16C650 (20x fanily)> port 0x3400-0x3407,0x3408
-0x340f irq 10 at device 7.0 on pci2
sio4: master device 0 not configured
sio4: configured irq 10 not in bitmap of probed irqs 0
sio4: type 16550A lookalike with 64 bytes FIFO (multiport)
sio5: master device 0 not configured
sio5: configured irq 10 not in bitmap of probed irqs 0
sio5: type 16550A lookalike with 64 bytes FIFO (multiport)
*** pucdata.c.orig Mon Nov 22 11:40:30 2004
--- pucdata.c Mon Nov 22 11:41:02 2004
***************
*** 539,546 ****
{ 0x131f, 0x2031, 0, 0 },
{ 0xffff, 0xffff, 0, 0 },
{
! { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
! { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
},
},
--- 539,546 ----
{ 0x131f, 0x2031, 0, 0 },
{ 0xffff, 0xffff, 0, 0 },
{
! { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ, 0x40000001 },
! { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ, 0x40000001 },
},
},
I'm not really sure why it works now, but it does :)
P.
On Mon, 22 Nov 2004, M. Warner Losh wrote:
> Date: Mon, 22 Nov 2004 17:36:36 -0700 (MST)
> From: M. Warner Losh <imp@bsdimp.com>
> To: gurney_j@resnet.uoregon.edu
> Cc: myj@nyct.net, freebsd-stable@FreeBSD.org
> Subject: Re: SIIG cards and puc
>
> In message: <20041122180515.GX57546@funkthat.com>
> John-Mark Gurney <gurney_j@resnet.uoregon.edu> writes:
> : Paul Sandys wrote this message on Mon, Nov 22, 2004 at 11:46 -0500:
> : > The SIIG card I have does use shared interrupt for both ports, so I don't see
> : > any other way around it.
> : >
> : > The 0x40000001 is a regular flag that's used by sio.c . I found an undocumented
> : > feature in there, that allows you to set a FIFO size, so I used it in
> : > combination with the shared irq flag.
> :
> : Ahh, yes... Then we now have the interesting problem that it appears
> : that PUC and sio share flags... :(
> :
> : from puc.c:
> : type = (sc->sc_desc.ports[i].flags & PUC_FLAGS_MEMORY)
> : ? SYS_RES_MEMORY : SYS_RES_IOPORT;
> :
> : and:
> : device_set_flags(sc->sc_ports[i].dev,
> : sc->sc_desc.ports[i].flags);
> :
> : which means you are also turning on memory mapping for the card...
> :
> : I'm not comfortable including a flag for an undocumented feature as a
> : standard part of the system.. Care to document it? :)
> :
> : Also, are you sure it's the ISMULTIPORT that needs to be set? (and not
> : the MEMORY flag you are acidentally also setting?) From what I've read
> : of the PUC driver, it handles the multiport case for you since it hands
> : out the interrupts to the sio driver... see this comment above puc_intr:
> : * This is an interrupt handler. For boards that can't tell us which
> : * device generated the interrupt it just calls all the registered
> : * handlers sequencially, but for boards that can tell us which
> :
> : hmmm.. that's probably how it gets around the fact that it doesn't need
> : to pass in the multiport flag, so we should probably be clearing that
> : flag before passing it down to the lower layers...
>
> You don't need the MULTIPORT to use PUC. If you do, then something in
> the tables is setup right. MULTIPORT is only for ISA cards. So
> that's clearly wrong.
>
> Can someone send me the patch for review. I've added devices to puc
> in the past.
>
> Warner
>
<-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_->
< myj@nyct.net Paul Sandys | New York Connect http://www.nyct.net >
< network operations manager | Total Solution provider >
<------------------------------------------------------------------------->
< " The Internet Solutions Provider You Can Count On ! " >
<-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_->
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041123002829.R70859>