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 :-)
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
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.
