From owner-freebsd-alpha Thu Jan 13 14:58: 0 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id B809C14CF1 for ; Thu, 13 Jan 2000 14:57:57 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id RAA22248; Thu, 13 Jan 2000 17:57:56 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id RAA88375; Thu, 13 Jan 2000 17:57:25 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Jan 2000 17:57:25 -0500 (EST) To: dfr@nlsystems.com Cc: freebsd-alpha@freebsd.org Subject: Cypress USB oddity X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14462.21106.354099.290960@grasshopper.cs.duke.edu> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message