>> The only reason this isn't done is because I, due to the
>> fledgling nature of the EISA code and the ahc VL card's
>> almost looking like EISA cards, did the wrong thing here.
>> We also need to be verifying that io ranges required to
>> probe for slots are not already claimed by other devices
>> before we blindly access them.  For this to all work with
>> the VL ahc cards, the EISA code will have to release all
>> resources associated with empty slots and the ahc driver will
>> have to grow an ISA front end.
>The EISA code currently doesn't reserve resources for empty slots.
>I'd like to make the bus driver reserve all EISA specific address space

This would prevent an ISA card that just happens to use an EISA
like identification scheme from attaching after EISA.  Unfortunately,
the 2842VL card does this.

>> I'm willing to help out on this work (still have a functional EISA
>> machine), but I stopped short last time over concern on how to support
>> Alpha/PA-RISC machines that might have multiple EISA busses.
>I can't see how multiple EISA busses would be possible.  While a PCI-EISA
>bridge might make it easier, you've only got one valid set of IO port
>ranges and ELCR ports.  I suppose you could remap the address space but
>who needs more than 10 EISA slots anyway?

I just want to make sure that we at least support the EISA Alpha
machines.  I honestly don't know how they were set up.

>> Is this stuff documented anywhere?  I've always wanted to gain access
>> to the aic7xxx card's nonvolatile region in the ELCR, but I could
>> never find out how to do this.
>Try ftp://ftp.jurai.net/users/winter/eisabook.zip

I can't seem to fetch it.  Permission denied.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to