This allows my TI1510 cardbus/PCI bridge to work after a suspend/resume,
without having to unload/reload the cbb driver.
I've also tested this on stable/9. I'll MFC it shortly.
PR: kern/170058
Reviewed by: jhb
MFC after: 1 day
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
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.
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.
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.
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.
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.
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)
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.
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.
o Don't busy wait on powerup. Instead, use the power up interrupt to wait
for the card to power up. Don't wait when we're turning the card off,
since no interrupt happens in that case.
o Convert many of the long DELAYs to tsleeps. We do not run before
the timer have stared, so DELAY isn't necessary. More DELAYs can likely
be eliminated in the future.
o When powering up the card, don't do anything if the card is already
powered up (before we'd power cycle it). This means that for most
cards we power them up once and then never change the power.
o On card eject, mask (by clearing) the CD bit. Before we set it, which
was wrong. We don't want to see any CD events past the first one since
they need to be debounced.
With these changes, I can insert/eject 16bit cards without glitching xmms'
sound output. Something very important to the development of better pccard
drivers :-)
pcib_route_interrupt interface. Since there's only one interrupt pin
in the CardBus form factor, everybody gets to share it. Implement
cbb_route_interrupt to return the interrupt we have.
Suggested by: bms
