Date: Thu, 11 Jan 1996 20:34:11 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Sujal Patel <smpatel@wam.umd.edu> Cc: "Amancio Hasty Jr." <hasty@rah.star-gate.com>, freebsd-hackers@freebsd.org Subject: Re: PnP problem... Message-ID: <199601111934.AA10845@Sysiphos> In-Reply-To: Sujal Patel <smpatel@wam.umd.edu> "Re: PnP problem..." (Jan 10, 21:22)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 10, 21:22, Sujal Patel wrote: } Subject: Re: PnP problem... } On Wed, 10 Jan 1996, Justin T. Gibbs wrote: } } > Yes, it would require a lot of work in the ISA area, but the PCI and EISA } > code could be changed to work this way rather easily. My init order } > is slightly different though: } [...] } > The listing is not complete, but you get the idea. You should keep this } > in mind while doing your PnP work since I think this is the approach } > we should be shooting for. First regarding Justin's message: Of course the probe and attach should be seperated, and I intend to change the PCI code accordingly. If I only had time to do it now ... } I have been keeping this in mind while I was coding. To change over to } a scheme that you described would be very simple. Right now, I just } gather the PnP configuration information from the kernel configuration; } this would simply change to information from PCI/EISA/ISA probes, after } the ISA code was cleaned up. } } A couple of quick questions: Is there a unified structure where one can } access the information from PCI/EISA/ISA probes? How well can the ISA } code non-invasively probe devices (currently)? I've been thinking about such a structure, and have written sown some first concepts. PCI seems to be a superset of the features required by EISA or ISA (it can need multiple memory and/or port regions). The data structure does either contain many pointers to arrays (e.g. containing bases, sizes, types of PCI memory mapped I/O regions), or there is an upper limit on the number of such regions, say 4 (which I'd strongly prefer). Don't have my notes here, but I was thinking about something like: struct memmap { unsigned long base; unsigned long size; unsigned long type; } struct iomap { unsigned long base; unsigned long size; unsigned long type; } struct intmap { inthand_t handler; unsigned char irq; unsigned char mode; unsigned char state; } struct devres { struct memmap[4]; struct iomap[4]; struct intmap; }; Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601111934.AA10845>