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>