summaryrefslogtreecommitdiffstats
path: root/sys/pccard
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Separate out isa attachment to its own file. The pci attachment willimp2001-05-163-84/+188
| | | | | | | | | | | soon attach directly to pcic rather than the kludge pci-pcic device we have now. In some ways, this is similar to the work PAO3 did to try to support cardbus bridges. In some ways different. This and future commits will be taking from the spirit of many of those changes. pcicvar.h is completely different from the pcicvar.h that appeared in PAO3, but similar in concept.
* This file is now obsolete. The #defines in it have never been usedimp2001-05-161-44/+0
| | | | and the pcic_devclass no longer is used by pccard.c.
* pcic98reg.h is now contained in meciareg.h.imp2001-05-152-59/+1
|
* The mecia support has moved to the mecia driver, so remove the copy ofimp2001-05-151-351/+35
| | | | it here.
* This code touches MD code inappropriately. So we have to include pc98imp2001-05-151-0/+5
| | | | specific file for pc98.
* A new driver for the MECIA. This is the NEC Original PCMCIAimp2001-05-152-0/+792
| | | | | | controller found in many of the early NOTE98 machines that were produced. This controller is completely unlike the intel 82365, so I've separated it out from the main pcic driver.
* {G,S}ET_UNIT are now unused, gc themimp2001-05-151-3/+0
|
* It turns out that pcic_slot::slotnum was really unused, so don't setimp2001-05-141-2/+0
| | | | it.
* Remove static array of slots. We now have state information for eachimp2001-05-141-17/+24
| | | | | slot in a softc for each unit that we probe. Also remove validunits static, since it is no longer necessary.
* Fix the so called "static bug" in polling mode. Some desktop cardsimp2001-05-141-6/+33
| | | | | | | | | | | | | | | | | | | | | | | | have bad grounding characteristics which allow small static discharges (or sunspots, we're not 100% sure which) to reach the bridge chip. This causes the bridge chip to wedge/reset itself. There's no known cure short of rebooting. The bug manifests itself by the STAT_CHG return 0xff when read. This is impossible because the upper bits are reserved (and therefore zero). In addition, some of the lower bits are one only for memory cards, which OLDCARD doesn't support, so if they are set, something seriously foobar'd is going on. So far we've seen this in exactly one brand of pcmcia <-> isa bridge which plug and play identifies only as "VIA PCMCIA CARD". This card just has buffers on the isa card and the actual bridge chip on the remote slot, which is connected by long ribbon cables. We think this long cable run, coupled with the lack of coupling capacitors is a major reason why it is so static sensitive while its bretheren aren't. Work Supported by: Timing Solutions, Inc. MFC After: 3 days
* Minor style(9) changes:imp2001-05-144-74/+78
| | | | return (VALUE);
* Take a stab at making this less dependent on having pcic as a parent.imp2001-05-141-24/+17
| | | | | | | For memory for the pccard attribute/common memory mapping allocate on the pccard. For other allocations, use whatever is the parent of this device. There's no doubt other issues lurking, but this should make things closer to being independent.
* Change machdep.pccard.pcic_mem_{start,end} to machdep.pccard.mem_{start,end}imp2001-05-141-10/+8
| | | | | | | since they have nothing to do with pcic and it makes grepping for pcic infection in pccard harder. MFC after: 3 days
* When activating or deactivating a resource, only attempt to deal withimp2001-05-141-0/+8
| | | | | | | | | | the resource activation if we're dealing with our grandchild. Otherwise, we run into two problems. One, if the pccard layer wanted to allocate and activate something, we'd wind up trying to do the wrong thing twice: the ivars are wrong and we don't want the bridge to map the resource to the slot. If we're more than a grandchild, then who knows what kind of ivar is present. In either of these cases, we just pass it up the food chain.
* Return errors for unsupported operations on pcic_get_res_flags ratherimp2001-05-131-1/+1
| | | | than 0.
* Change #ifdef PC98 to #ifdef MECIA_SUPPORT and define MECIA_SUPPORTimp2001-05-131-13/+17
| | | | | | when PC98 is defined. This is in perparation for a mecia driver separate from pcic, assuming that all goes well with that effort. MECIA_SUPPORT won't be removed until after that support is working.
* I'll be making some rather substantial changes to the pci attachmentimp2001-05-131-1/+1
| | | | | | of the pcic class of devices. Go ahead and move it to the "usual" place. I say "usual" in quotes since it isn't exactly right (not in dev/blah), but it is closer than before.
* o Get rid of static array of slots in pccard layer. Move this to theimp2001-05-134-102/+100
| | | | | | | | | softc. o Store pointers to softc in dev_t in si_drv1. o Change 'kludge version' to 'classic version' since things are getting less kludgy. o Minor code shuffling so that we probe and attach the pccard slots. o Minor style(9) changes.
* Th -> The in a commentimp2001-05-121-1/+1
|
* Use enumeration values for CARD_SET_RES_FLAGS.dmlb2001-05-081-4/+13
| | | | | | | Remove panic on out of range io window and return ENXIO. Add a similar check for memory windows. Approved by: imp
* Add a sysctl pair for the pcic memory allocation rangedmlb2001-05-081-3/+16
| | | | | | | | | | | | | machdep.pccard.pcic_mem_start machdep.pccard.pcic_mem_end and default the range to IOM_BEGIN/IOM_END. This may prove useful to if_ray users (and others) on more modern hardware that maps BIOS stuff into 0xd000-0xdffff. MFC: after 1 week Approved by: imp
* Ricoh RL5C46x cardbus bridges have the bits for 3E0 and 3E2. Theimp2001-05-081-4/+0
| | | | | | RL5C47x cards do not. Only set them for that set of bridges. Submitted by: shiba (Takeshi Shibagaki-san)
* Add some additional register definitions for some work I have in progress.imp2001-05-081-0/+2
|
* Set the slot pointer in the pc98 case. Correct the name of the bridgeimp2001-05-071-2/+5
| | | | | | | | chip to the one that the Japanese use. Now we get insert/remove events on my PC-9821Ne. More work in bus space is needed to make drivers work. MFC after: 3 days
* Disable the card after sending the removed event up to the pccardimp2001-05-071-1/+1
| | | | | | | | | | | | | | | | layer. This fixes an ordering problem that would cause the ISR for the device to run with now power applied to the device. Most cards failed to deal with this gracefully, and thus would hang on card eject. The power down event, for those keeping score, is what causes the interrupt for the card. Many folks in the Japanese nomads list have reported this, so I'll be MFCing quickly for their benefit. Submitted by: Masayuki FUKUI MFC after: 2 days
* My fix to NEWCARD for getting the function type broke oldcard due toimp2001-04-211-2/+2
| | | | | | | | a name conflict. Pointed out by: markm # I had to login to freefall to make this commit, so something maybe up
* Set the device name for NEC PC98 PCMCIA Controller on boot.imp2001-04-211-18/+19
| | | | | # We really need to allocate i/o ports for it, but I need to learn # the pc98 bus space better before attempting that.
* Indirect off cinfo rather than calling pcic_ functions directly. Thisimp2001-04-191-12/+12
| | | | | | | means that the pcic98 functionality might now work (I've tested it on my pcic machine, but not the pcic98). Since these functions are rarely called, it is unlikely that this will have a measurable impact on performance.
* First cut at bringing NEC PC98 original pccard bridge code back intoimp2001-04-194-47/+372
| | | | | | | | | FreeBSD. This code doesn't work just yet, but does compile. We need to start indirecting via the cinfo pointers, rather than directly calling pcic_*. There may be other issues as well, but you gotta start somewhere. Obtained from: PAO3
* Move setting of TI113X_PCI_CARD_CONTROL register soonerimp2001-04-171-3/+2
|
* Minor comment that missed the last changeimp2001-04-171-1/+1
|
* When booting, turn on the 3E0 compatibility address for ricoh cardbusimp2001-04-172-3/+32
| | | | | | | | | | | parts. This is based on the newcard code that turns it off :-). We can now reboot after NEWCARD or Windows and have OLDCARD work. Add support for the RL5C466 while I'm at it. Treat TI1031 the same as the CLPD6832. It doesn't work yet, but sucks less than it did before. Also add a few #defines for other changes in the pipe.
OpenPOWER on IntegriCloud