summaryrefslogtreecommitdiffstats
path: root/sys/pccard
Commit message (Collapse)AuthorAgeFilesLines
* When including pci header files, do things differently for 5x and 4ximp2001-07-191-0/+7
| | | | | | | to make code sharing between the two easier. Also, only do power management in -current. It doesn't exist in stable yet.
* Use INTR_TYPE_AV rather than INTR_TYPE_MISC for the interrupt forimp2001-07-101-1/+1
| | | | pci interrupts for the bridge.
* Note that spls are noopsimp2001-07-091-0/+2
|
* Cleanup some obsolete commentsimp2001-07-061-2/+3
|
* Combine a couple of tests to reduce the indentation level.imp2001-07-011-9/+7
|
* Some interrelated interrupt changes.imp2001-07-012-15/+49
| | | | | | | | | | | | | | | | | | | | | | | | | Frist, for pci slots, make the setup intr save the requested interrupt vector and arg and return rather than passing it up to our parent. On interrupts, we call this vector iff there's a card in the slot. This should eliminate some of the hangs or "weird" messages that people see when ejecting cards and also help close the race window somewhat. Reading the pci bus one more time for this information is judged to be an acceptible tradeoff since it is very very fast. Cleanup a little how we detect unsupported cards. Only detect unsupported cards (eg cardbus cards) on card insertion (or more pedantically when a card is actually present). This should allow us to change the message in the future to "cardbus card not supported with OLDCARD" :-). Note: We may also consider this for the ISA bus case, but there the reads are much more expensive and the location of the CD pin status lines appears to be less standardized. Also, the ISA management interrupt isn't shared with the card's interrupt. The mutliplex the CSC and function interrupts bit also appears to be non-standard (or at least not imlemented on all bridges).
* Write zeros into the base/bounds register bars. We need to do thisimp2001-07-011-0/+16
| | | | | | | | because NEWBUS (and I think some versions of Windows sometimes) writes 0xffffffff to these registers to disable them. When they are "disabled" like this, writing memory ranges to the pcic registers are ignored and you will get "card (null) (null)" when you insert a call otherwise.
* First cut at getting the pcic controller and power information forimp2001-07-011-32/+62
| | | | | | each of the bridge chips. Before we wrongly assumes that all cardbus bridge chips were intel compatible step A/B. This mostly worked, but likely caused problems with certain cirrus logic cardbus bridges.
* Clarify some of the 3.3V code with better comments. Also, since theimp2001-07-011-6/+12
| | | | types are treated as a bitfield, test them as such.
* Add comments explaining why we do the somewhat odd irq mapping on PC98imp2001-07-011-0/+7
| | | | machines with C-BUS cards.
* Minor whitespace nit.imp2001-07-012-2/+2
|
* Work around a bug in the current interrupt system by explicitlyimp2001-06-251-0/+4
| | | | | | | | | | | | rejecting INTR_FAST interrupts. Since they can't be shared anyway, this just short circuits a failure case that should work but is panic fodder now. This bug is that if the interrut condiation is active when you activate the interrupt, then the interrupt routine will be called. jhb had a patch that may or may not work to fix it, but I've lost it. This may be due to the sio probe doing something odd too.
* Some people are having problems with insert/eject. Add some debugimp2001-06-161-0/+4
| | | | | | | | information until the problems can be tracked down. Right now these are unconditional, but later it will be hidden behind a boot verbose. Also, if there are no events listed in the event mask, return right away. Specifically avoid writing back interrupt acks in this case.
* Save the IRQ that we get in pci attachment.imp2001-06-163-15/+15
| | | | | | | | | | | Print type of pci bridge we find. Force the IRQ of pci bridges upon all its children. Allocate the resources on behalf of the bridge when we're testing to see if they exist. This should help people who don't read updating instructions very well. This patch started out with an idea from Shigeru Yamamoto-san in -current.
* On PC-98, map IRQ 6 to IRQ 7 at the pcic level. That is, when we'reimp2001-06-163-4/+17
| | | | | | | | | | | | told to use IRQ 6, progam the pcic to use irq 7 instead. Evidentally, at least some of the cards are wired this way. If you want to use irq 6, configure it. All the mapping is done just before we set the interrupt registers. See [FreeBSD98-testers 5064] for details. Added commentary about valid interrupts on some CBUS pc98 CL PD6722 based cards. Submitted by: Hiroshi TSUKADA-san <hiroshi@kiwi.ne.jp>
* First stab at adding back in CL-PD6729 support.imp2001-06-091-1/+15
|
* Add PC9801-102 CBUS card to the list of plug and play devices. Someimp2001-06-091-0/+1
| | | | | | | mapping of irq 6 may be required to use that irq, but if so, additional commits will follow. Submitted by: Hiroshi TSUKADA-san
* Go ahead and request 0x44000000 through 0xfffffff instead of justimp2001-06-081-1/+1
| | | | | | 0xefffffff # Note, this is bogus, but less bogus than before.
* The TI-1031 is more like the TI-113x chips rather than the 12xx orimp2001-06-081-2/+3
| | | | | | | | higher chips. Treat it as if it were a 113x. This is correct as far as 16-bit cards go, at least how we're using it. # It appears that my TI-1031 based pci card that YAMAMOTO shigeru-san gave # me on my trip to Japan now works.
* If the chip isn't in power state D0, put it in power state D0. Iimp2001-06-041-10/+12
| | | | | | | | | | | elected to do this in the probe rather than the attach so that we don't disturb things which this might reset. different cards have different quirks, according to their datasheets. This should fix the "I booted in windows and rebooted to FreeBSD and now things don't work" problem. PR: 4847, 20670
* Add new pci attachment for pcic. This supports pci cards as well asimp2001-06-042-165/+288
| | | | | | | | | | | | card bus bridges. We now always use pci interrupts for pci cards. This will allow us to more easily configure things. You must change your IRQ lines in /etc/pccard.conf to match what we've probed. I'm not sure the right way to deal with this right now. Development of pci pcmcia has been funded by Monzoon Networks AG. I am grateful for their generosity.
* #defines for pci way interrupt routing.imp2001-06-041-0/+33
|
* Move the pcic interrupt from pcic.c to pcic_isa.c. The ISA handlingimp2001-06-043-128/+138
| | | | | | | | | | | | | | for card change interrupts is different than the pci stuff that's coming soon. Set the management irq in different ways. If pci_parallel interrutp routing, then use the PCI way of getting interrupts. Move polling mode into pcic_isa since when we're routing via pci polling doesn't work because many bridges (systems hang solid). If we're routing interrupts via pci, they can be shared, so flag them as such. Note, this doesn't actually change anything since the pci attachment isn't quite ready to be committed.
* Minor style(9) nit. a|b -> a | b.imp2001-06-041-1/+1
|
* Change plxic to plxcard, per phk. He thnks plxic is too generic aimp2001-06-012-75/+71
| | | | name. I didn't do repo magic because this is so new.
* Add a simple plx pci9052 based pccard bridges. This doesn't work yet,imp2001-05-312-0/+455
| | | | | but I'll be fleshing this out as I have time. This should mean we no longer need to have an and wi pci attachments, but that's a ways off.
* Turns out that one bit isn't enough. Introduce two new fieldsimp2001-05-283-16/+39
| | | | | | | | | | | | | | csc_route and func_route to hold the way that each interrupt is routed. csc is Card Status Change in the datasheets and standard, but is called "Management Interrupt" in FreeBSDese. There are three types of interrupt routing: ISA parallel, PCI parallel and ISA serial (some chipsets support other types as well, but I don't plan on supporting them). When we try to allocate an interrupt, and the type for that interrupt is pci_parallel, allow it to be shared by oring in RF_SHAREABLE to the flags argument. Introduce pcic_alloc_resource to allow this to happen.
* Allow a shareable interrupts. Note, the bridge must set this flag orimp2001-05-272-15/+16
| | | | | | | | the irq will be unshareable, as things are now. More work likely is needed, but this is a good checkpoint. # pcic_pci.c is getting closer :-)
* Fix a minor formatting nitimp2001-05-251-1/+1
|
* Move to using the common device list.imp2001-05-252-119/+99
| | | | Move to table driven probing of these devices since we have such a long list.
* Migrate from unit based to dev base. Don't save unit number, but do saveimp2001-05-253-13/+15
| | | | | dev. Convert all uses of unit to dev as appropriate. Minor comment fixes to pcic_softc definition.
* Update copyright infoimp2001-05-255-6/+6
|
* Add intrack field to each slot. This can be used to acknowledgeimp2001-05-252-0/+4
| | | | | | | interrupts on other buses. Right now it isn't used, but will be for the pci attachment. # Add copyright by me for this year since I've changed so much.
* Minor name space issues.imp2001-05-251-19/+20
|
* Use bus_space functions rather than inb/outb.imp2001-05-245-20/+28
| | | | | | | Add defines for PCIC_INDEX and PCIC_DATA offsets. Change PCIC_INDEX_0 to PCIC_PORT_0 Add define for PCIC_NPORT. Document why the vadem probe works.
* Do what we should have done a long time ago:imp2001-05-241-0/+10
| | | | | | | | | | | o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_PCMCIA and programming interface is 0, assume that it is a generic PCMCIA PCI chip we can program. I don't think there are any of these that we don't know about, but you never know. o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_CARDBUS and programming interface is 0, assume that it is a YENTA cardbus bridge that we know how to cope with. There are likely some cardbus bridges that haven't it made it in here yet.
* Move getb1 and putb1 from pcic_isa.c to pcic.c. Rename them toimp2001-05-243-22/+24
| | | | | | pcic_{get,put}b_io. There are some pci bridges (the CL-PD6729 and maybe others) that do not have memory mapped registers, so we'll need these in both places. Declare them in pcicvar.h.
* Add better support for the Ricoh 5C296 and 5C396 chips. These chipsimp2001-05-234-9/+28
| | | | | | have a slightly different 3.3V support than the other clones, so compensate as best we can. Note: 3.3V support is untested since I do not have any 3.3V cards that I know of to test it with.
* Add recognition for Toshiba ToPIC-100.imp2001-05-232-0/+4
| | | | Submitted by: Shimodaira Toshio <tshimod1@ym.nsw.co.jp> in [bsd-nomads:15589]
* Move allocation of ExCA registers from the base driver into the busimp2001-05-213-34/+17
| | | | attachment code.
* Move setting of Vcc bit to before the vcc switch statement. Theimp2001-05-211-7/+5
| | | | | datasheets I have seem to indicate that generally this bit is viewed as a toggle. Correct comments to match code.
* Next step on the road to pci: power taming.imp2001-05-214-84/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Work through the various power commands and convert them from a "is this a foo controller or a foo' controller or a foo''' controller" to a cabability based scheme. We have bits in the softc that tell us what kind of power control scheme the controller uses, rather than relying on being able to enumerate them all. Cardbus bridges are numerous, but nearly all implement the i82365sl-DF scheme (well, a few implement cirrus CL-PD67xx, but those were made by Cirrus Logic!). Add a pointer back to the softc in each pcic_slot so we can access these flags. Add comments that talk about the issues here. Also note in passing that there are two differ Vpp schemes in use and that we may need to adjust the code to deal with both of them. Note why it usually works now. We have 5 power management modes right now: KING, AB, DF, PD and VG. AB is for the i82365 stpes A, B and C. DF is for step DF. PD is the cirrus logic extensions for 3.3V while VG is the VADEM extensions for 3.3V. KING is for the IBM KING controller found on some old cards. # I'm looking for one of those old cards or a laptop that has the KING # bridge in it. We have to still cheat and treat the AB parts like the DF parts because pci isn't here yet. As far as I can tell, this is harmless for actual old parts and necessary to work with 3.3V cards in some laptops. This almost eliminates all tests for controller in the code. There are still a few unrelated to power that need taming as well.
* Next step towards pcic_pci: the ability to allocate mapped memory in attach.imp2001-05-213-11/+72
| | | | | | | | | | | | | | | | | | | o Introduce flags word to the softc. This will be used to control various aspects of the driver. Right now there are two bits defined, PCIC_IO_MAPPED and PCIC_MEM_MAPPED. One for ISA cards that are I/O mapped, the other is for PCI cards that are memory mapped. Only the ISA side is implemented with this commit. o Introduce a pcic_dealloc which will cleanly dealloc resources used. Right now it is only supported when called from probe/attach. o Keep track of resources allocated in the pcic_softc. o move pcictimeout_ch to the softc so we can support multiple devices in polling mode. o In ISA probe, set PCIC_IO_MAPPED. o Introduce and compute the slot mask. This will be used later when we expand the number of slots on ISA from 2 to 4. In such a case, we appear to have to use polling mode otherwise we get two different cards trying to drive the same interrupt line. I don't have hardware to test this configuration, so I'll stop here.
* Two comments and one bug fix:imp2001-05-212-3/+15
| | | | | | | | | | o Add defines for the VS[12]# bits in register 0x16. o Add comment about what we're doing reading register 0x16 (PCIC_CDGC) in the DF case. o Check bit VS1# rather than a random bit I was checking due to a bogus transcrition on my part from nakagawa-san's article. o Add note about IBM KING and 3.3V operation from information larned from wildboard.
* Add back the plain i82365 to the list of bridges that do specialimp2001-05-191-0/+1
| | | | | | | | | things to get 3.3V. It appears that some cardbus chipsets have id registers that say they are C step parts, but they really support the DF step 3.3V functionality. # Need to verify that IBM KING is handled properly since the MISC1 # register is really a cirrus logic only register.
* Initialize cinfo structure at compile time rather than run time sinceimp2001-05-192-34/+29
| | | | they are now constant.
* slots and next haven't been used in a while. GC them.imp2001-05-191-6/+0
|
* Now that we've moved the mecia support out of pcic.c to its ownimp2001-05-191-12/+12
| | | | | driver, we no longer need to go through the cinfo.XXXX indirections. restore the direct calls that were replaced earlier.
* Move ISA specific code into pcic_isa. This is the probe routine, theimp2001-05-193-262/+255
| | | | | get/setb1 routines. Also expose clrb and setb as pcic_{clrb,setb} so we can use it from the probe. pcic_probe is no longer needed.
* It turns out that Intel's i82365sl-DF step has the same ID as the VLSIimp2001-05-192-31/+62
| | | | | | | | | | | | | | | | | | | | | | | | | 82C146. The Intel i82365SL-DF supports 3.3V cards. The Step A/B/C parts do not appear to support this. This is hard to know for sure since it was deduced from "compatible" parts' data sheets and the article mentioned below. Rework the VLSI detection to be a little nicer and not depend on scanning cards twice. This would allow bad VLSI cards to coexist with a good intel card, for example. We now detect i82365SL-DF cards where before we'd detect a VLSI. For the most part, this is good, but we run a small chance of detecting a single slot 82C146 as a i82365SL-DF. Since I can't find a datasheet for the 82c146, I don't know if this is a problem or not. This work is based on an excellent article, in Japanese, by NAKAGAWA, Yoshihisa-san that appeared in FreeBSD Press Number 4. He provided a patch against PAO3 in his article. Since the pcic.c code has changed some since then, I've gone ahead and cleaned up his patch somewhat and changed how the code detects the buggy '146 cards. I also removed the comment asking if there were other cards that matched the 82C146 since we found one and additional information isn't necessary.
OpenPOWER on IntegriCloud