Re: vx driver patch
On Wed, 8 Nov 2000, Warner Losh wrote: In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Wed, 8 Nov 2000, Warner Losh wrote: : The cardbus code, for example, will or in the RF_SHAREABLE bit when : appropriate. : : Right, but the drivers that are consumers of the PCI or CARDBUS bus : interface shouldn't have to deal with RF_SHAREABLE; the bus driver should : do that. I grant you that this isn't the case at the moment but it should : be. We are in violent agreement. The cardbus bridge code is the one that adds RF_SHAREABLE in the right places. We currently have about 146 calls to bus_alloc_resource() for SYS_RES_IRQ. Most seem to get this wrong. E.g.: - pci drivers "know" that pci interrupts are shareable and force RF_SHAREABLE. Is this required by the pci spec? - the isa compatibility code and pcvt force RF_SHAREABLE although isa irqs are rarely shareable. - sio forces !RF_SHAREABLE, but it is possible for sio interrupts to be shared if they aren't fast. - the pci compatibility code forces RF_SHAREABLE, except for fast interrupts it forces !RF_SHAREABLE. This overloads RF_SHAREABLE to mean that the device driver supports sharing. Perhaps this is what RF_SHAREABLE as supplied by drivers should mean. The bus level can match it with shareability actually available and maybe reprogram that shareability to match what the driver prefers. This seems to require more flags for requires/prefer/no_preference/cant_do. Non-shared resources should degrade gracefully to shared ones if a driver that requires shared is attached after a driver that prefers non-shared. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Peter Wemm wrote: Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. What machine and what does the output from the probe/attach look like? You'll fail the attach because the ID is not in the table of known EISA IDs. Joerg can probably give additional examples of this problem. This is one reason we don't probe all 15 slots yet. If we reserved the address space properly before doing the probe and also only performed the probe if the mainboard ID is valid, this wouldn't be an issue any longer. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
What machine and what does the output from the probe/attach look like? You'll fail the attach because the ID is not in the table of known EISA IDs. I forgot to mention that the probe will cause the aic78XX controller to get very upset as you end up referencing a register that should only be referenced while the chip is in a paused state. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Justin T. Gibbs wrote: You'll fail the attach because the ID is not in the table of known EISA IDs. Joerg can probably give additional examples of this problem. This is one reason we don't probe all 15 slots yet. If we reserved the address space properly before doing the probe and also only performed the probe if the mainboard ID is valid, this wouldn't be an issue any longer. What about EISA/VL or EISA/PCI systems? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
What about EISA/VL or EISA/PCI systems? What about them? PCI devices are supposed to be found via PCI configuration space access. Even in these machines where a PCI card can be falsly probed as an EISA card, the standard PCI configuration mechanism works to correctly find PCI devices. VL cards are identified using ISA probe techniques in all cases I'm aware of. It just turns out that the 2842 uses a scheme that is very similar to that of an EISA card. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
Humm... I had wondered why that was there. Is there a way to detect VLB devices some other way? This is specific to the aha2842 and is the only way I know of detecting those boards. I thought that there was a tricky way, which involved doing the EISA non-destructive card identification, and then throwing out those things that hadn't registered themselves with the EISA BIOS, but it's been a while since I looked at it. My main concerns on this were: 1) Not incorrectly identifying a VLBUS card as an EISA card; the code used to do this, way back when, on a per driver basis, by not using the EISA BIOS, and scanning for the EISA ID (which these cards had). 2) Not blindly allocating the entire EISA space, which could conflict not only with VLBUS, but (at the time) some ENPIC assignments made by one of the PCMCIA bridge chipsets that were being used with VLBUS laptop video systems. If I remember correctly, the was to fix this was to identify the VLBUS card, both through the probe approach (which was not destructive, as above, because it was only applied to SCSI controllers after they were known to be there, and other VLBUS cards were identifiable), AND through the EISA BIOS. If a card showed up in the first place, but not the second, then it was a VLBUS card with an EISA table in it (I can't remember how, but the EISA BIOS knew not to treat these as EISA cards). This added an ugly third stage, so it went: VLBUS, EISA probe, AHA2842, EISA attach 8-(. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Terry Lambert wrote: (I can't remember how, but the EISA BIOS knew not to treat these as EISA cards). Because the EISA Config Util. saves the config to the system NVRAM which the EISA BIOS reads to get the configuration. Using the EISA BIOS stuff might be the way to go. I'm really pissed that I've never been able to get the resource stuff to work correctly as that would make the EISA subsystem in FreeBSD more or less like the PCI/ISAPNP subsystem. (In the sense that drivers wouldn't have to query the card for resources.) How do we use the EISA BIOS on an Alpha or an SGI though? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
What about EISA/VL or EISA/PCI systems? What about them? PCI devices are supposed to be found via PCI configuration space access. Even in these machines where a PCI card can be falsly probed as an EISA card, the standard PCI configuration mechanism works to correctly find PCI devices. VL cards are identified using ISA probe techniques in all cases I'm aware of. It just turns out that the 2842 uses a scheme that is very similar to that of an EISA card. As a backgrounder for other-than-Justin, Adaptec has a habit of making multipurpose ROMs that sit on different types of devices, so that they don't have to maintain multiple images. It's the EISA stuff in these ROMs that causes a non-EISA BIOS based EISA probe to incorrectly identify them as EISA. If I understand one of Justin's comments in this thread correctly, an additional layer is required for proper ordering, since he has a VLBUS device that shows up in the EISA BIOS based probe; this abstraction would be needed to allow the treatment to be uniform, instead of adding another "rogues" table to handle such things. I also seem to remember something about it being necessary to bouce buffers for the thing on a particular chipset (CMD?) where the address lines at 16M and above weren't properly bridged, so if it were misidentified as EISA, it would get very, very unhappy. My personal experience with EISA/PCI and EISA/ISA has been a net positive. I've never seen an EISA with VLBUS in the flesh, but I remember that they existed for a short while before PCI to let people use non-EISA video cards, because it was cheaper than an EISA video card of equal performance. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
(I can't remember how, but the EISA BIOS knew not to treat these as EISA cards). Because the EISA Config Util. saves the config to the system NVRAM which the EISA BIOS reads to get the configuration. Yes, that was how, thanks for jogging my memory... Using the EISA BIOS stuff might be the way to go. I'm really pissed that I've never been able to get the resource stuff to work correctly as that would make the EISA subsystem in FreeBSD more or less like the PCI/ISAPNP subsystem. (In the sense that drivers wouldn't have to query the card for resources.) How do we use the EISA BIOS on an Alpha or an SGI though? There was a documented way to do this on the Alpha, but it turns out that it wasn't necessary, since it didn't have the failings of the PC architecture. At one (gross) time in history, Alphas included an x86 emulator in ROM to facilitate this (and other BIOS POST initialization stuff, mostly). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
What about EISA/VL or EISA/PCI systems? What about them? PCI devices are supposed to be found via PCI configuration space access. Even in these machines where a PCI card can be falsly probed as an EISA card, the standard PCI configuration mechanism works to correctly find PCI devices. VL cards are identified using ISA probe techniques in all cases I'm aware of. It just turns out that the 2842 uses a scheme that is very similar to that of an EISA card. As a backgrounder for other-than-Justin, Adaptec has a habit of making multipurpose ROMs that sit on different types of devices, so that they don't have to maintain multiple images. It's the EISA stuff in these ROMs that causes a non-EISA BIOS based EISA probe to incorrectly identify them as EISA. This is not correct. You are making this all much more confusing than it is. The 2842 will not be identified as an EISA device by the system BIOS or any other OS but FreeBSD. This is because you must *write* to the "EISA like" ID registers prior to reading them in order for them to return somthing other than 0. So, if our EISA probe stops poking the ID registers prior to reading them, the 2842 will not be seen. Secondly, there are some PCI systems that lack EISA slots entirely, but map device register space in traditionally EISA slot address ranges. Some of the aic78xx cards just happen to have registers in these locations that have values that satisfy an EISA probe. Of course, you're not supposed to be poking them in this way once the card is setup and, should the EISA code honor address reservations made by the system, as well as whether an EISA mainboard controller is found, these conflicts just wouldn't happen. All other VLB cards I know of look just like their ISA counterparts from a probe perspective. They shouldn't enter into this discussion. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
How do we use the EISA BIOS on an Alpha or an SGI though? I believe thorpej recently committed some code in NetBSD to do this on the Alpha. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
As a backgrounder for other-than-Justin, Adaptec has a habit of making multipurpose ROMs that sit on different types of devices, so that they don't have to maintain multiple images. It's the EISA stuff in these ROMs that causes a non-EISA BIOS based EISA probe to incorrectly identify them as EISA. This is not correct. You are making this all much more confusing than it is. The 2842 will not be identified as an EISA device by the system BIOS or any other OS but FreeBSD. This is because you must *write* to the "EISA like" ID registers prior to reading them in order for them to return somthing other than 0. So, if our EISA probe stops poking the ID registers prior to reading them, the 2842 will not be seen. OK, I'm wiling to buy this; I was never really enticed into buying a VLB card, I'm only speaking from when VLB card support screwed me over when I had an EISA box with a 1742. I was just fearful that the 2842 wasn't the only snake in the grass out there, and so (as usual, I guess) wanted to solve for every instance of the possible problem space so we would never have to do it again, for all eternity. The address space issues with VLB vs. EISA that I mention are real, but in like of your "there is only one rogue" argument, I think we can avoid referencing the EISA MindShare book, unless someone cares to nominate another rogue (I expect this will never happen, since VLB is for all intents and purposes, as dead a technology as when the idiots first introduced it... 8-)). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Terry Lambert wrote: At one (gross) time in history, Alphas included an x86 emulator in ROM to facilitate this (and other BIOS POST initialization stuff, mostly). Somehow I doubt I'll be able to make VM86 calls to BIOS interrupt services on the Alpha. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Thu, 9 Nov 2000, Terry Lambert wrote: : At one (gross) time in history, Alphas included an x86 emulator in ROM : to facilitate this (and other BIOS POST initialization stuff, mostly). : : Somehow I doubt I'll be able to make VM86 calls to BIOS interrupt services : on the Alpha. I think you are right. Even if the emulator ws there, it was only used to run the ROM post code, not to be active any time after the boot to use at randomly... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
At one (gross) time in history, Alphas included an x86 emulator in ROM to facilitate this (and other BIOS POST initialization stuff, mostly). They still do. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Warner Losh wrote: I think you are right. Even if the emulator ws there, it was only used to run the ROM post code, not to be active any time after the boot to use at randomly... I looked at the NetBSD/Alpha EISA code. Looks like that does everything we'll need. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in the case where the IRQ is shared with another device. So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? The current EISA code isn't as smart as it should be. I've got uncommitted code that ties it to the ELCR. Bus front end code shouldn't have to know about level/edge triggered IRQs. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? The current EISA code isn't as smart as it should be. Speaking of that, I'd like to see the EISA code move to be more like PCI. We should see if there is something at slot 0 and only then attempt to probe for sub-devices on the bus. 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. 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've got uncommitted code that ties it to the ELCR. 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. Bus front end code shouldn't have to know about level/edge triggered IRQs. So long as the ELCR is guaranteed to work. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : Bus front end code shouldn't have to know about level/edge triggered IRQs. The cardbus code, for example, will or in the RF_SHAREABLE bit when appropriate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: Speaking of that, I'd like to see the EISA code move to be more like PCI. We should see if there is something at slot 0 and only then attempt to probe for sub-devices on the bus. Humm... I've got EISA BIOS extension code that correctly returns IDs but not resources for a given slot. I suspect that nobody actually implemented that part of the spec. 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 though. 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've got uncommitted code that ties it to the ELCR. 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. Humm... Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't remember where I got it at the moment but its a pretty good reference. Bus front end code shouldn't have to know about level/edge triggered IRQs. So long as the ELCR is guaranteed to work. It is. I've been running the code for almost 6 months. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Warner Losh wrote: The cardbus code, for example, will or in the RF_SHAREABLE bit when appropriate. Right, but the drivers that are consumers of the PCI or CARDBUS bus interface shouldn't have to deal with RF_SHAREABLE; the bus driver should do that. I grant you that this isn't the case at the moment but it should be. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Wed, 8 Nov 2000, Warner Losh wrote: : The cardbus code, for example, will or in the RF_SHAREABLE bit when : appropriate. : : Right, but the drivers that are consumers of the PCI or CARDBUS bus : interface shouldn't have to deal with RF_SHAREABLE; the bus driver should : do that. I grant you that this isn't the case at the moment but it should : be. We are in violent agreement. The cardbus bridge code is the one that adds RF_SHAREABLE in the right places. This should allow us, in the fullness of time, to share interrupts for the 16-bit cards in cardbus sockets, for example, w/o sharing them for those cards in a i82365SL socket. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
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 though. 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. Humm... Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't seem to fetch it. Permission denied. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't seem to fetch it. Permission denied. Damn firewall. Try with passive mode off. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
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 though. 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. There are a huge number of VESA Localbus cards that identify as EISA cards, including having all the EISA device identifier stuff in tehir ROMs. The disk controllers are the worst, but I have seen at least two video boards that do the same thing. Though I'd like to deprecate VESA Localbus as an abomination, I guess it has to be supported. Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Terry Lambert wrote: Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? The only reason is to return the EISA probe to a read-only probe. The ahc VL cards require that their ID0 register be written too prior to reading the ID byte. This isn't required for true EISA cards and may prove harmful to other devices that just happen to be in that space. For instance, some PCI devices can be identified as EISA cards if you probe the full EISA bus blindly. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: The only reason is to return the EISA probe to a read-only probe. The ahc VL cards require that their ID0 register be written too prior to reading the ID byte. Humm... I had wondered why that was there. Is there a way to detect VLB devices some other way? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
Humm... I had wondered why that was there. Is there a way to detect VLB devices some other way? This is specific to the aha2842 and is the only way I know of detecting those boards. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
"Matthew N. Dodd" wrote: On Wed, 8 Nov 2000, Terry Lambert wrote: Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Peter Wemm wrote: Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. What machine and what does the output from the probe/attach look like? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
Someone (I can't find who in my records, please let me know if it was you so I can credit you in the commit message) sent out patches to make the vx driver not use the pci compat shims. I just found it in my home directory, applied it, tweaked things very minorly and it builds and boots. Trouble is, I don't have a vortex to test with. It also appears that there is no driver maintainer at this time, so I thought I'd send it here. Unfortunately, there are a couple of problems with this patch. Somebody tried copying the EISA attachment code too closely: there's only one I/O space that needs to be allocated (the pci_io allocation is bogus). The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in the case where the IRQ is shared with another device. Also, the vx driver still uses the ugly hack of statically allocated softc structs. I was working on this in the office the other day and just got done testing it. I have patches to fix all of this, plus make it use the bus_space_*() stuff instead of inb/outb/etc, plus allow it to be compiled as a KLD. The only thing I didn't do was implement detach routines, which means the driver can be loaded as a KLD, but not unloaded. The driver should also build in the alpha. I'll commit the changes to -current shortly. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
At Sun, 05 Nov 2000 01:26:42 -0700, Warner Losh [EMAIL PROTECTED] wrote: I think this means lnc is the last one in the tree, but I could be wrong about that. I didn't do an actual grep... # find /usr/src/sys -type f |xargs grep COMPAT_PCI_DRIVER ./dev/hea/eni.c:COMPAT_PCI_DRIVER (eni_pci, eni_pci_device); ./dev/hfa/fore_load.c:COMPAT_PCI_DRIVER(fore_pci, fore_pci_device); ./dev/pdq/if_fpa.c:COMPAT_PCI_DRIVER (fpa, fpadevice); ./dev/vx/if_vx_pci.c:COMPAT_PCI_DRIVER (vx, vxdevice); ./dev/sym/sym_hipd.c:COMPAT_PCI_DRIVER (sym, sym_pci_driver); ./dev/lmc/if_lmc_fbsd3.c:#ifdef COMPAT_PCI_DRIVER ./dev/lmc/if_lmc_fbsd3.c:COMPAT_PCI_DRIVER(ti, lmcdevice); ./dev/lmc/if_lmc_fbsd3.c:#endif /* COMPAT_PCI_DRIVER */ ./dev/lnc/if_lnc_pci.c:COMPAT_PCI_DRIVER (lnc_pci, lnc_pci_driver); ./i386/isa/rp.c:COMPAT_PCI_DRIVER (rp_pci, rp_pcidevice); ./i386/isa/stallion.c:COMPAT_PCI_DRIVER (stlpci, stlpcidriver); ./pci/cy_pci.c:COMPAT_PCI_DRIVER(cy_pci, cy_device); ./pci/if_en_pci.c:COMPAT_PCI_DRIVER (en, endevice); ./pci/if_sr_p.c:COMPAT_PCI_DRIVER (sr_pci, sr_pci_driver); ./pci/meteor.c:COMPAT_PCI_DRIVER (meteor, met_device); ./pci/simos.c:COMPAT_PCI_DRIVER (simos, simos_driver); ./pci/pcivar.h:#define COMPAT_PCI_DRIVER(name, pcidata) \ ./pci/if_ar_p.c:COMPAT_PCI_DRIVER (ar_pci, ar_pci_driver); ./pci/alpm.c:COMPAT_PCI_DRIVER (alpm, alpm_device); -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
There is a minor typo in the URL. The patches are at: http://people.freebsd.org/~imp/if_vx.patch Jim Bloom [EMAIL PROTECTED] Warner Losh wrote: Someone (I can't find who in my records, please let me know if it was you so I can credit you in the commit message) sent out patches to make the vx driver not use the pci compat shims. I just found it in my home directory, applied it, tweaked things very minorly and it builds and boots. Trouble is, I don't have a vortex to test with. It also appears that there is no driver maintainer at this time, so I thought I'd send it here. Please review my patches at http://people/.freebsd.org/~imp/if_vx.patch I'd like to commit this in a few days. If you have a vortex board, please give it a spin with these patches and let me know if there are any problems. If you have any problems with the patches, let me know. I'll commit this next weekend or so if there are no outstanding issues by that time. I think this means lnc is the last one in the tree, but I could be wrong about that. I didn't do an actual grep... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
