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.
socket also supports the voltage. Some XV cards have appeared on the
scene (or cards that report they support XV), and in older machines
that have sockets that do not support XV, we were bogusly trying to
power them at XV rather than at 3.3V. Now, power up the card at the
lowest voltage supported by both the card and the socket.
MFC After: 3 days
than just deleting them. Also add comments about why we do this.
Given the current behavior of delete_child, I don't think this changes
anything. It just feels cleaner.
try very hard to be perfect. However, these attempts broke down when
there were large numbers of resources. We'd not be able to map them all.
Instead, accept that we might pass more range to thse subbus than
might be optimal be able to compute. However, there's little harm in
this and it allows us to pass greater resources through.
# it has been suggested that we allocate a fixed amount of resources
# on attach and give it out upon request. This might not be a bad idea...
the ExCA spec, and close cousins:
o Write an activate routine that works.
o merge a couple of items from oldcard before they are lost
o write a deactivate routine
I suspect we're still a ways away from having this work, but maybe for
6.1/5.5?
o Rather than just try to turn off EXCA_INTR_RESET, set the entire register
to 0. This is slightly faster, and a better hammer.
o Move attempted clearing of the output enable (EXCA_PWRCTL_OE) back to
after we turn off the power. Modify it to write 0 so that we don't get
Bad Vcc messages on TI bridges (untested, but ru@ sent me a similar patch)
while at the same time avoiding interrupt storms on Ricoh bridges (tested
by me on my Sony).
# Many of my observations of 'breakage' for this patch are due to some bug
# in the load/unload of cbb.ko unlreated to this change. I'll be investigating
# and fixing that bug in the fullness of time.
16-bit cards when we're powering them up. Other bridges may have
similar issues, so we do this for all of them by setting the
interrupt in the PCIC register 3 to be 0 (done always anyway)
and turning on the bit in the bridge control register to route these
interrupts via the ISA bus (or via the interrupt configured in the
PCIC register 3). '0' means disable completely. There's a small
chance this may interfere with the o2micro power hacks, but I'll
wait for reports to come in from o2micro users.
o Expand some of the comments about why we do certain things.
# this gets rid of the interrupt storm warnings on my 505TS. I think
# that we may need to do something similar on suspend, but I'm unsure
# since I don't have a laptop that supports suspened/resume with a
# ricoh chipset in it.
card. Mask it while we're doing power things, as the PC Card standard
suggests. Also, poll the POWER_CYCLE bit 10x a second as well as
providing a timeout for power cycle interrupt to happen.
The Ricoh '475 that I have doesn't seem to generate an interrupt for
power at the present time, so the polling is necessary for reasons as
yet unknown. This results in an interrupt storm warning that I'm
still trying to quantify (the o2micro trick doesn't work to mitigate
this storm). At the very least, this should help those users that
lost pccards on boot with the prior rev of this code. My VAIO
PCG-505TS is now happier, but more investigation is necessary.
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
the data sheets leads me to believe these will just work. Those parts
with the various media readers on them may not have the required
FreeBSD drivers that will attach to the subdevices that will be seen
on some of these parts.
PCI 1515, 1530, 1620, 4520, 6411, 6420, 7410, 7510, 7610
Prompted by: Havard Eidnes
These are from the datasheets downloaded from TI's web site.
They describe the PCI[67]x[12]1 and PCI[67]x20 parts, with and without
the smartcard enabled.
to try to allocate things on my parent can be taken out. It duplicates code.
Also, add comment about why the power state stuff is here (type 2
devices don't participate in the power state save/restore due to
larger Bx issues).
secondary bus is 0, we program the primary bus, the secondary bus and
the suborindate bus. This isn't ideal, since we start at parent_bus +
1 and store this in a static.
Ideally, we'd walk the tree and assign bus numbers. However, that's
harder to accomplish without some help from the bus layer which we're
not planning on doing that until 6.
This fixes my CardBus problems on my Sony PCG-Z1WA, and might fix the
Dells that have had problems.
Alignment for pccards should also be treated in a similar way that
we tread it for cardbus cards.
Remove bogus debugs while I'm here.
# This is also necessary to make the CIS reading work.
Submitted by: Carlos Velasco
o O2Micro OZ711e1 is now recognized (note: I don't have one, and the current
owner of the Dell laptop is reporting problems).
o minor nits wrt copyright date.
giant, which implies that we need to take out giant it we're NOT
MPSAFE.
# I can't believe the number of people that looked at this failed to
# detect this.
CB710, CB720, CB1211, CB1225, CB1410 and CB1420
These are likely licensed designed from TI, and the Linux PCMCIA code
treats them as TI chips.
Add comment, but no ID for the 711E1 from O2Micro.
present, and non-zero when it is (or may be) absent. The test
cbb_child_present was backwards. However, typical usage in the tree
would cause it to do the right thing because the card really wasn't
there the OK flag would be turned on.
Also, assume that if any of these bits are turned on we don't have a
card, rather than requiring both of them in the suspend/resume
routines.
Noticed by: cognet
the time the card is inserted and the time that the card is
configured. This can lead to interrupt storms. The O2Micro suggested
workaround is to route the card function interrupt to IRQ1. It
appears from my testing that this is an acceptable workaround for most
chipsets (there's still some issue with the ricoh chipset).
Also, only look at the NOT_A_CARD bit when the bridge tells us there's
a card present. At least one test caused this to be true after the
card was removed, but the author couldn't recreate it with the
workaround in place. The change is more conservative than the
previous code, but still has the work around that wasn't present in
the older code.
the standard.
1) When the bridge tells us that we have a card that isn't recognized, we
use the force register to force the CV_TEST to run. This test causes the
bridge to re-evaluate the card. Once this re-evaluation process happens,
we get a new interrupt that may say it is ready to process. We try this up
to 20 times. Tests have shown that this appears to correctly reset the
'Unknown card type' problem that I saw on my Sony PCG-505TS.
2) Take a page from OLDCARD and always read the CSC register in the ISR.
Some TI (and it seems maybe Ricoh) chipsets require this to behave
properly. This work around appears to work due to some power management
protocols that were improperly implemented. Maybe it can be removed when
this driver supports the full PME# protocol described in the standards.
3) Minor additional debug printf when debugging is enabled.
4) Minor additional commentary for things that are obvious only after study.
# I'm committing this from my Sony PCG-505TS using shared PCI interrupts
# and NEWCARD, but there are some issues with the Ricoh bridge still, but
# at least now I can boot with the card inserted and have it work.
However, they are presently necessary due to bigger bogusness in the
pci bus layer not doing the right thing on suspend/resume or on
initial device probe. This is exactly the sort of thing that the
BURN_BRIDGES option was invented for. Mark all of them as
BURN_BRIDGES. As soon as I have the powerstate stuff properly
integrated into the pci bus code, I intend to remove all these
workarounds.
o Register ISR INTR_MPSAFE.
o Loop on KTHREAD_DONE == 0 in the thread.
o Safe the INTR_MPSAFE flag for client drivers (don't know if there are any
CardBus/PCI drivers that are INTR_MPSAFE)
o Read status after acquiring mtx_lock(Giant) rather than before so that we
catch state changes that happen while Giant is being acquired.
o Turn off the CD bit when we see a CD interrupt, and turn it back on after
we've attached/detached the card.
o On suspend, actually set the CBB_SOCKET_MASK to zero rather than oring
in '0' to turn it off on suspend.
o If the ISR that's registerd is MPSAFE, don't acquire Giant around call to
client ISR.
o Fix comments to reflect these changes.
obtained from o2micro. These should only be needed for 'older'
o2micro bridges (anything before the 7xxx series of bridges), but will
work with the new bridges.
# I don't plan on porting it to oldcard, but will happily commit to
# oldcard if someone else needs them.
o Only complain about detached children that aren't pccard/cardbus.
o Don't NULL out the pccarddev and cbdev devices. detach just
disassociates the device and driver. It doesn't delete the child.
o on driver added, just probe_and_attach the children. If there's
any children attached, wakeup the device add/delete thread.
o wakeup the add/delete thread with the correct cv_signal() rather
than the bogus wakeup(sc). It used to be that we did a tsleep on
sc in this thread, but switched to the more reliable cv stuff a while
ago w/o changing this.
o Remove bogus checks when reallocating memory for the registers. They
weren't needed and turned out to be completely bogus.
This lets me load/unload pccard with a pccard in a slot and have the
child correctly detach/attach. This should help people that have wi
in their kernel, but that kldload cbb and pccard, for example.
we can have additional different types of bridges.
o remove now bogus comment.
o Don't clear CARD_OK when we can't attach a card.
o minor style nits
# this make kldload of cardbus drivers work for me when the card is
# present on boot.
