From owner-freebsd-alpha Fri Jan 14 12:30:30 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 66E4914CEE for ; Fri, 14 Jan 2000 12:30:22 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA80310; Fri, 14 Jan 2000 09:06:32 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 14 Jan 2000 09:02:07 +0000 (GMT) From: Doug Rabson To: Andrew Gallatin Cc: freebsd-alpha@freebsd.org Subject: Re: Cypress USB oddity In-Reply-To: <14462.21106.354099.290960@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 13 Jan 2000, Andrew Gallatin wrote: > > The Cypress USB controller (function 3 of the 82C693) used on later > Digital Personal Workstations and all XP1000s & DS20s is somewhat odd. > It is a PCI device, but it apparently wants to use an ISA interrupt > (10) and has a truely bizzare irq in its pci config space (234). This > results in the usb driver failing to aquire an irq: > > ohci0: mem 0x1094000-0x1094fff irq 234 at device > 7.3 on pci0 > ohci0: could not allocate irq > > The 82C693 has 2 IDE controllers on it as well: > > ata-pci0: port 0x10000-0x1000f,0x > 3f4-0x3f7,0x1f0-0x1f7 irq 238 at device 7.1 on pci0 > <...> > ata-pci1: port 0x374-0x377,0x170- > 0x177 irq 239 at device 7.2 on pci0 > > They would have the same problem except for the fact that their I/O > base addrs match the primary & secondary I/O port addresses for IO_WD1 > & IO_WD2. Because of this, they end up using the > alpha_platform_setup_ide_intr() code which does the right thing and > allocates them ISA irqs. > > What is the right way to handle the USB function? Do we need a > similar hack? > > I have noticed that if you mask those irq's with 0xf, you get the isa > irq that it wants. So I was thinking that we could catch this in the > pci chipset code by looking for a bizzare irq, then setup the > appropriate isa irq. This sounds pretty disgusting -- is there a > better way? > > Thanks, This number is 0xe0 + isa irq. I think that some versions of SRM are using this range specifically to describe ISA irqs. If we supported this explicitly (maybe in cia.c - pci.c doesn't really need to hear about it) it might tidy up both this and also the ugly mess of the ide interrupts. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message