From owner-freebsd-hackers Fri Jul 16 11:54:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id F3BF1156C2; Fri, 16 Jul 1999 11:53:59 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id TAA01289; Fri, 16 Jul 1999 19:33:37 +0200 (CEST) (envelope-from se) Date: Fri, 16 Jul 1999 19:33:37 +0200 From: Stefan Esser To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: Help with PCI code understanding Message-ID: <19990716193337.A1213@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG Mail-Followup-To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG References: <378E553B.E6C71B0B@cs.binghamton.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <378E553B.E6C71B0B@cs.binghamton.edu>; from Zhihui Zhang on Thu, Jul 15, 1999 at 05:40:12PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-07-15 17:40 -0400, Zhihui Zhang wrote: > Can someone outline the initialization process of PCI devices in > FreeBSD? I know many of the basic stuff of PCI introduced in the book > "PCI System Architecture". I just want to know how each driver is > registered into some linker set and its probe routine gets called. In > other words, I want to know the major data structures and routines and > their relationship. I wonder if there is already a document somewhere. I'll explain what the PCI code in -stable (my code) does. There is a new device framework in -current, which emulates the old interfaces, but will require changes to device drivers for simplicity and full support of the newly offered features. For now, you can assume the PCI code as in -stable, which will continue to be supported for some more time, AFAIK ;-) If you are only interested in the PCI probe, then you best look at one of the small wrappers /sys/pci/if_ed_p.c or /sys/pci/if_lnc_p.c, for example. You provide the PCI code with a struct pci_device, that specifies the name of the driver, the address of the probe function, the address of the attach function, the address of a unit number counter and finally the address of a shutdown function (NULL in most drivers). The probe function receives as the first argument an opaque value, that is used to identify this particular device to the other PCI subroutines, and the PCI vendor and device ID as a 32 bit value as the second argument. The probe function returns a NULL pointer if the probe fails, a string that identifies the device in case of a match, or an empty string in case the device was recognized but should be silently ignored. The attach function receives the same first argument as probe, and the unit number to assign to thos device as the second argument. The unit number is not necessarily just one more than for the previous device attached by the PCI code. (There is support for "wired" devices, i.e. assignment of unit numbers to controllers in specified PCI slots, for example if you have several SCSI cards and do not want your controllers (and drives) be renumbered in case one card is not present or defective. But this is a little used and hidden feature ...) PCI devices can be compiled as modules and will be probed/attached exactly as explained above after being dynamically linked into the running kernel. Let me know if you have any further questions. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message