Subject: Re: PMS driver and ISA
To: Matthias Drochner <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 02/09/1996 14:18:53
On Fri, 9 Feb 1996 13:29:07 +0100 (MET)
Matthias Drochner <firstname.lastname@example.org> wrote:
> Wonderful - this is what I was waiting for. Hope it will be generic enough
> to be used for other address maps too - I'm concerned about hardware
> with some live insertion capabilities (not PCMCIA).
Yah ... What I ended up having to do to manage the ISA io/mem space
sanely was implement a new "extent manager", which I'm finishing up now.
rmap wasn't flexible enough, and if I added the flexibility, it became a
> If you touch the ISA code anyway, you should think of the "plug and play"
> cards which can probably not be ignored in the future (at least, if you have
> to share the machine with M$ victims). I recently got the PnP 3c509 working,
> but the binding to the existing if_ep driver is somwhow unsatisfying.
> The ISA PnP spec allows for up to 4 memory windows, 8 io ranges, 2
> interrupts and 2 dma channels per logical device. The ressource
> allocation is managed by the BIOS - very PCI-like. (I'm quite familar
> with it - ask if you need more details.)
If you could mail me *all* of the details, I'd be happy to at least look
at it. :-)
> You are confusing me a bit. Al least in the -current sources, ISA uses
> config_scan(). Seems that you describe the _basic_ idea only - there
> must be more...
Umm ... You're right ... I misread config_scan(). Ok .. a small change
to each of the config_*() functions that search cfdata ... how's that?
:-) This includes config_scan() and config_search(), and
config_rootsearch(), too, actually. The change to these functions will
be *really* trivial.
> Anyway, I'd suggest thinking about loadable driver issues before
> doing these changes. It seems that not all cases can be handled -
> if a device whose driver is not present gets messed up in the first
> autoconf run, the loaded driver has no chance...
> On the other hand, loadable driver support probably requires some more
> additions to struct cfdriver. (And, imo, in the config_search and
> related functions.)
Yah .. I'm not convinced that we're really in any condition to deal with
most forms of loadable drivers at the moment. This example is a shining one.
> It would be nice if the different improvements could be coordinated.
Yup. SPEAK UP, FOLKS! :-)
> I'll look at your changes next week. I hope I can apply them,
> my devolopment tree is basically release 1.1.
You should be able to...They're pretty simple/straightforward.
Jason R. Thorpe email@example.com
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939