summaryrefslogtreecommitdiffstats
path: root/sys/dev/pccbb
Commit message (Collapse)AuthorAgeFilesLines
* Hold off root mounting until we've gone through the loop of our threadimp2009-02-173-0/+11
| | | | | | | almost once. After we've configured the devices that were present the first time through, then we know that we're done. If the device has other devices that are deferred, then it must do a similar dance. This catches both PC Cards and CardBus cards.
* Correct signatures to match kobj function definitions.imp2009-02-043-22/+19
|
* Update to the interrupt handling code:imp2008-12-111-35/+58
| | | | | | | | | | | | | | | | o Try to be smarter about reading the ExCA CSC register. Now, we only do it for 16-bit cards. Add some experimental code to treat it like a power interrupt, but I'm not 100% sure that I like it. It may be removed upon further testing. It seemed to help in one test case, but the evidence may be inconclusive. This may be beneficial for cleaning up exca_reset and exca_wait_ready. o Check for CSTS events on the socket event register. We ask for it when we're powering up a card, but I don't think we're otherwise using it. Just ACK the interrupt for now. In theory, we can use it instead of the busy wait we do in cbb_cardbus_reset. More research is necessary to see if we can optimize things there when we're waiting for the DEVVENDOR register to become valid. o Rework the comments a bit. Minor tidying up. Etc.
* Minor tweaks to some of the comments. Also, add a XXX wondering if weimp2008-12-071-17/+18
| | | | | need to frob the 16-bit EXCA registers during the new interrupt-driven power-up sequence.
* Use '0' rather than PZERO to not change the priority that I'm waitingimp2008-12-071-3/+3
| | | | | | | | | | at. I don't think this will make a huge difference, but I have received a report of a interrupt storm on one 16-bit card that this might fix (chances are it won't, since I think that we may need to check both the CBB registers for the 16-bit card as well as the PCIC registers for power state change). Submitted by: jhb@
* Use atomic_add_int rather than a simple ++ to ensure no cache races ifimp2008-12-071-1/+1
| | | | | | | | the power interrupt and init code waiting for the interrupt are running on different CPUs. I haven't seen this make any real difference, but I've also had some reports of odd behavior I can't otherwise explain. It is an infrequent operation, and certainly wouldn't hurt.
* Move to using filter for the change interrupts. Also rework the powerimp2008-12-053-37/+24
| | | | | | interrupt code to be more robust. I've been running these changes for over a year... With these changes, I don't see the ath card going into reset like the code in the tree.
* Minor style nit.imp2008-12-051-2/+2
|
* Augment comments, and move things around a smidge.imp2008-12-051-17/+17
|
* Implement a method described in NetBSD PR 36652 for coping with theimp2008-12-051-1/+12
| | | | BAD VCC bit.
* Return BUS_PROBE_GENERIC rather BUS_PROBE_DEFAULT for generic CBB we match.imp2008-10-021-1/+1
| | | | Reviewed by: jhb@
* Don't forget to match on a CLASS of PCIC_BRIDGE as well as subclassimp2008-10-021-1/+4
| | | | PCIS_BRIDGE_CARDBUS. Otherwise, we may hit a few false positives....
* Read the config space of the child, not the bridge, to determine whenimp2008-08-101-5/+5
| | | | the child is out of reset... <blush>
* fix typoimp2008-08-091-1/+1
| | | | Submitted by: N.J. Mann
* It turns out that checking the first DWORD register is more reliableimp2008-08-091-15/+17
| | | | | | | on a variety of cards. Adjust the comments accordingly to match the code. Even if the vendor chose 0xffff for the device ID, the vendor ID can't be 0xffff, so the test is still valid from a standards perspective.
* After some intial testing, there are even slower cards than the onesimp2008-08-091-13/+24
| | | | | | | | | | | | | | | | | | that I have. Wait up to 1.1s for the card to become ready. Document what the standards say, and use that to justify the behavior in the code: PCI standard says that a card must respond to configuration cycles within 2^25 cycles after reset goes high, which is approximately 1s. Therefore, give cards a little break and wait for up to 1.1s for VENDOR to become valid. Only look at the vendor part of the ID, since only it can't be 0xffff (although in practice vendor/device will always be != 0xfffffffff). Include detailed pointers to standards so epople understand why we're doing what we're doing and why it just might be OK. Make it clear in the timeout message that it is just a warning, sinc we try to soldier on as best we can anyway. This should eliminate an error message that r181453 produced on certain Atheros cards.
* Rather than waiting a fixed amount of time, which might not be enoughimp2008-08-091-12/+23
| | | | | | | | | | | | and also holds things up, check every 20ms to see if we can read the vendor of device 0.0. It will be 0xffffffff until the card is out of reset. Always wait at least 20ms, for safety. I think this is a better fix to the reset problem. However, I did it as a separate commit in case something bad happens, people can roll back to the commit before this one to see if that gives them reliable behavior. I don't have FreeBSD up on enough machines to do exhaustive testing on all known bridges...
* While most bridges can bring a card out of reset in 20ms, there areimp2008-08-091-3/+4
| | | | | | | | | | | | | | | | some bridge + card combinations that take longer for reasons unknown. Adjust the timeout to be 100ms on all !RICOH bridges, but leave RICOH at 400ms. The 400ms is "lore" from other open source projects, and I've never see my ricoh bridge chips take this long. Maybe it is the same thing? Maybe a bit should be read instead of a hard-wired pause? After this adjustment, a few cards that I'd insert and get only: cbb0: card_power: 3V cbb0: card_power: 0V with full debugging enabled would actually try to attach. Reported by: sam@ (I think) MFC after: 3 days
* Rename the kthread_xxx (e.g. kthread_create()) callsjulian2007-10-202-4/+4
| | | | | | | | | | | to kproc_xxx as they actually make whole processes. Thos makes way for us to add REAL kthread_create() and friends that actually make theads. it turns out that most of these calls actually end up being moved back to the thread version when it's added. but we need to make this cosmetic change first. I'd LOVE to do this rename in 7.0 so that we can eventually MFC the new kthread_xxx() calls.
* Make the PCI code aware of PCI domains (aka PCI segments) so we canmarius2007-09-303-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
* Migrate from setting a CARD_OK flag in a shared word, to setting itsimp2007-06-043-32/+21
| | | | | | | | | | | own entry in the softc. This should allow more of cbb_pci_intr() to migrate to a new cbb_pci_filt() so that we don't have to run cbb's ISR in almost every case we get an interrupt. We can't just move cbb_pci_intr into cbb_pci_filt because it does things that aren't safe to do from a fast interrupt handler, err I mean from a filter. This is an important first step. # I wonder if I need to make cardok volatile or not.
* Don't register cb_func_filt if the client driver doesn't have a filter.imp2007-06-041-4/+3
| | | | | | ditto for the isr. Reviewed/Suggested by: simokawa-san
* Minor filter tweaks:imp2007-06-031-26/+47
| | | | | | | | | | | | | | | | | o If we don't have a filter, also check to make sure the card is there before calling the scheduled ISR. This is necessary to help old drivers whose ISRs can't cope with being called with the hardware missing, which sadly still exist in the tree. This is the main reason why we have an extra layer of indirection for cardbus interrupts. o If the card is no longer present, mark the interrupt as 'handled' rather than 'stray' because this accounts for why the interrupt happened. Stray isn't all bad, since there are other filters that would claim it... o Fix some comments + Add comment about why we check for CARD_OK and touch the hardware in both the filter and ISR. + add a note about why we don't care about Giant + also note that giant can't be taken out in a filter... + Some minor formatting nits on very long comments.
* Make the interrupt handler wrapper capable of correctly support ↵piso2007-05-312-8/+22
| | | | | | filter+ithread handler. Discussed and reviewed with: bsdimp, simokawa
* o Don't hold lock over bus_teardown_intr when we're waiting for theimp2007-05-161-5/+3
| | | | | | thread to die, since that can cause deadlock with the ISR (in theory). o Minor cleanup o comment nit
* Better message on cbb resource alloc failureimp2007-05-161-1/+1
|
* Use different wait channel name for second of two sleeps. Minor commentaryimp2007-03-051-2/+2
| | | | addition.
* Reduce the number of retries to 10 from 20 for not_a_card retry test.imp2007-03-041-5/+8
| | | | | | | | Add some comments to explain how 10 was picked. 20 was completely arbitrary, at least 10 has some reasoning behind it. Also, update the comments about how long we sleep to reflect the new, shorter timeout we use.
* Use pause() instead of tsleep()'s on the softc pointer that have nojhb2007-02-271-6/+6
| | | | | corresponding wakeups. Also, at least some of the comments nearby indicate that these are fixed-length I/O sleeps.
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-233-5/+7
| | | | | | | | | | | | | bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
* Two changes:imp2007-02-161-1/+4
| | | | | | | | | | | | | | (1) change debounce period from 1s to 250ms. This appears to be fine and speeds things up a little. (2) In the middle of cbb_pcic_power_disable_socket we write 0 to the EXCA_INTR register to put the card into reset. However, this turns off CSC interrupts for TI bridges (and maybe others). So no further card insertion events would be noticed. To compensate, after we've gone through the entire power down sequence, turn on EXCA_INTR_ENABLE so that CSC events happen. #2 should fix the 'dead slot' problem that has been reported after card ejection (but only 16-bit cards).
* Fix typo in commentimp2007-02-161-1/+1
|
* It turns out that it is easier to not NULL out pccard and cardbusimp2007-02-151-14/+6
| | | | | | | | device pointers. They don't change as the children device drivers come and go. Rather, check to see if the device is attached where we would have checked ! NULL. This solves many asymmetries in the code that likely could lead to crashes when loading/unloading cbb without one or more of the expected children's driver not present.
* Fix three bugs:imp2007-02-151-6/+25
| | | | | | | | | | o When detaching all children, try really hard to get all the children list before giving up. This is based on an observation by hans petter selasky in his usb p4 branch. o When rescanning devices after a driver is added, abort if we can't get the child list with a message. o when rescanning devices, if the reprobe/attach is successful, save the device for cardbus/pccard.
* Batch of changes:imp2006-08-123-61/+112
| | | | | | | | | | | | | | | | | | | o when turning off the socket for a 16-bit card, write 0 to INTR register rather than just tying to just clear the rest bit. this seems to fix card insert detection after an eject on TI bridges (ricoh bridges work either way, apparently). This is a MFp4. o Cope better with TOPIC95 bridges on powerup. According to NetBSD driver, these bridges don't set POWER_STATE, so cope accordingly in our power code. They also need a little extra time to settle, so do that as well. o It appears that we need to turn on/off one of the clocks to the card when we power up/down that socket on a TOPIC97, also from NetBSD. o TOPIC97 bridges need to specifically enable LV card support. Unconditionally do this in the hopes that all laptops that have these chips support LV voltages (they should, since they are required for CardBus). o TOPIC register name regularization. Registers specific to models of TOPIC are now called out as such. # I need a machine with a TOPIC95 for testing.
* We don't have a ISA specific shutdown routine at this time, so removeimp2006-06-031-1/+0
| | | | | | it. We just moved it to be pci specific, so this was causing compile problems (linking problems, so I didn't notice since I unwisely just built the module).
* Since we turn off the interrupts, we don't need to disestablishimp2006-06-031-13/+0
| | | | our ISR.
* Move shutdown, and pci specific methods into pccbb_pci.c. Many moreimp2006-06-033-74/+67
| | | | are needed still.
* The interrupt routine is pci specific. Move it into pccbb_pci.c.imp2006-06-032-70/+71
|
* Fix a couple printf's to be properly terminated.imp2006-06-031-3/+3
| | | | Use a better name for the cbb thread.
* Succeed for writing bus value... nobody that calls must care :-(imp2006-06-031-1/+1
|
* Zero out the devices when they are deleted. We can access the pointer afterimp2006-06-021-1/+5
| | | | the bus detaches which can lead to core dumps. This is quite rare.
* Export the pribus, secbus and subbus as sysctls for informationimp2006-05-242-20/+31
| | | | purposes only. Additional information may be exported in the future.
* Suspend the children before we turn off card events in hardware. Thisimp2006-05-241-2/+4
| | | | | | | | was done, I believe, to work around some cards having issues in the suspend case. I think that this helped my Sony VAIO TS505 work better when it had certain wireless cards in it and I did a apm -z. I've not tested suspend/resume on other laptops in a long time, so I hope this doesn't cause greif. Please let me know if it does.
* Fix a race when detaching the cbb worker thread. There were a coupleimp2006-05-241-1/+7
| | | | | | of cases where we didn't take out the lock before setting or clearing a bit. This apparently can lead to a race at kldunload time (at least on my Turion64 laptop, never saw it on my Sony Vaio).
* Whitespace nitsimp2006-05-231-3/+3
|
* Since DELAY() was moved, most <machine/clock.h> #includes have beenphk2006-05-162-2/+0
| | | | unnecessary.
* Add missing ~. We want all the INVALID bits to be 0... Let's see if thisimp2006-04-161-1/+1
| | | | helps people with their interrupt storm problem on card eject.
* On some laptops, under very high loads, the socket event register readimp2006-03-301-2/+13
| | | | | | | | | | | | in the ISR doesn't read the actual socket event register, but instead reads garbage (usually 0xffffffff, but other times other things). This totally violates the PCI spec, but happens rarely enough that a workaround is in order. This adds one test when we have a real interrupt to service (which is very rare), and doesn't affect the usualy 'nothing to see here' case at all. Problem reported by many, but sam@ gave me this workaround after diagnosing the problem.
* Add a mask of valid socket eventsimp2006-03-301-19/+20
| | | | While I'm hear, fix define<sp> to be define<tab>.
OpenPOWER on IntegriCloud