request and just calling it when we get a bridge interrupt. The
problem is that if other code wants to block hardware interrupts for a
little bit with splXXX, those masks aren't updated the way we're doing
it. This doesn't matter for -current, but does for -stable.
The whole reason that we were catching interrupts was to detect that
the card was still there. Ian's fixes however ensure that the card
will be there with an interrupt handler, or not there at all. Since
the pcic interrupt is at a high priority, this should be OK.
This should fix the network related crashes people started seeing in
stable after I merged the pcic as a pci device code.
Submitted indirectly by: Ian Dowse
MFC when: Ian has had a chance to do his torture hang testing.
the ISR. We keep track of the card state and don't call the IRS when
the card isn't inserted. This helps quite a bit with card ejection
problems that Ian was seeing.
Submitted by: Ian Dowse
MFC upon: re approvel.
assing an IRQ. Add better comments while I'm here.
MFC after: 1 day
# Note: That's merging all the -current pci pcic code, not just this one
# change for the Aug 15th code freeze.
register. It enables Zoom Video. It appears that on at least one
card that Monzoon is using sets these bits by default. Nothing works
when these bits are set, everything works when they are clear.
Add commentary on some of the ti bits. Make code a little clearer.
Also remove a call to pcic_pci_pd6729 which was prematurely added in
the last commit.
can't blindly write zero into it to disable the card. We must
preserve this bit. This changes pcic_disable to only clear the bits
we know we need to clear on card disable, thus preserving the magic
bit for many TI bridges.
This appears to have fixed the problems that people are reporting
about the system failing to recognize cards being inserted or removed
(or both). Greg: This may fix your problem too :-).
is the diagnostics register at offset 0x93. When bit 5 is set in this
register, bits 4-7 in ExCA register 0x5 being 0000 are required for
pci interrupt routing. When it is clear, then bit 4 of ExCA register
0x3 is used to enable it.
The only other issue is that when you route interrupts this way, you
must read ExCA register 0x4 in order to clear the interrupt, else you
get an interrupt storm.
Deal with this requirement by setting things up. It is believed that
this won't hurt other chipsets, but other chipsets may require their
own work arounds.
o Move PIOCSRESOURCE from pccard to pcic so the kernel can give pccardd
better hints as to what resources to use.
o Implement an undocumented hw.pcic.interrupt_route to allow people that
need to do so to route their interrupts in a non-standard way.
o Only preallocate a resource in probe if we're routing via pci.
o If we aren't routing via pci, then set the irq to use explicitly
to defeat the automatic IRQ routing of the pci layer.
This, with the pccardd code should be close to what can be committed
to -stable.
resources it is attempting to assign to a child object. This should
help people track down mysterious resource allocation problems more
easily.
# Unfortunately, it is harder to do the conflict check and report which
# resource failed if the driver itself doesn't.
strictly necessary on current, but having it in here makes the diffs with
stable smaller and doesn't hurt anything except for phk's redundant include
finder.
hw.pcic.irq Globally set the IRQ for all pcic devices' management
interrupt (aka card status change or CSC interrupt)
This is what used to be known as
machdep.pccard.pcic_irq (which has been retained for
now for compatibility).
hw.pcic.ignore_fuction_1 Ignores function 1 for all PCIC bridges by not
attaching to them. Lucent released a huge batch
of cards that were imporperly manufactuered (lacking
the 0 ohm resister to disable slot 1). This is
a big hammer to keep those cards from causing problems
(I've had 4 people contact me saying my patches
worked great once they added a kludge to always ignore
function 1, or until they soldered these resistors
in place!).
No clue where to document these. They act as both boot loader environment
variables, as well as read-only sysctls after boot.
At the same time, sort sys/systm.h in its proper order after sys/sysctl.h.
o kill blank line that I introduced in cardinfo.h
o Delete unused variable wasinactive.
o return 0 from pccard_resume.
o Set the state and lastsate initially to be empty.
o move comment above code for interrupt dispatching.
o Powerstate interface is now available as of 430002, not 500000 (note that
this change will be not 100% correct since the power state stuff didn't
enter current until well after 500000, but it is good enough for the two
branche we have going now).
power x 0.
pccardc power x 0 used to disable the slot. But a suspend/resume
would reactivate the pccard. It no longer does that. Now the
disabling of the slot is sticy until it is reset with power x 1 or the
card is ejected. This seems closer to correct behavior to me.
o Process all card state changes the same using pccard_do_stat_change().
o Cleanup disabling the card so that we can preserve the state after
the change. Basically, don't set it to empty as often as we do.
o On suspend, the new state is "empty" and the laststate is "suspend"
o Document state machine with a diagram of states and edges. The
edges are labeld to tell the reader what event causes the external
state changes.
o "machdep.pccard.pcic_resume_reset" may be obsolete now. We always
call the bridge driver's resume method on resume now. Otherwise cards
won't automatically show up. If it needs to stay, I'll add it back.
longer have a pccard in the slot. This fixes the problem where pccard
would say that a card had been inserted on resume. This also appears
to make the insert/remove events more reliable after a resume as well,
but that may be a different bug I need to hunt down.
Sometimes, when pccardd is restarted, it fails to realize that the
device is already attached and tries to attach it again. This leads
to bad mojo since the pccard code isn't setup to handle that, so the
panic was put in. Now it appears that it is triggering too easily, so
I'm backing it off to a non-fatal error.
Frist, for pci slots, make the setup intr save the requested interrupt
vector and arg and return rather than passing it up to our parent. On
interrupts, we call this vector iff there's a card in the slot. This
should eliminate some of the hangs or "weird" messages that people see
when ejecting cards and also help close the race window somewhat.
Reading the pci bus one more time for this information is judged to be
an acceptible tradeoff since it is very very fast.
Cleanup a little how we detect unsupported cards. Only detect
unsupported cards (eg cardbus cards) on card insertion (or more
pedantically when a card is actually present). This should allow us
to change the message in the future to "cardbus card not supported
with OLDCARD" :-).
Note:
We may also consider this for the ISA bus case, but there the
reads are much more expensive and the location of the CD pin
status lines appears to be less standardized. Also, the ISA
management interrupt isn't shared with the card's interrupt.
The mutliplex the CSC and function interrupts bit also appears
to be non-standard (or at least not imlemented on all
bridges).
because NEWBUS (and I think some versions of Windows sometimes) writes
0xffffffff to these registers to disable them. When they are
"disabled" like this, writing memory ranges to the pcic registers are
ignored and you will get "card (null) (null)" when you insert a call
otherwise.
each of the bridge chips. Before we wrongly assumes that all cardbus
bridge chips were intel compatible step A/B. This mostly worked, but
likely caused problems with certain cirrus logic cardbus bridges.
rejecting INTR_FAST interrupts. Since they can't be shared anyway,
this just short circuits a failure case that should work but is panic
fodder now.
This bug is that if the interrut condiation is active when you activate
the interrupt, then the interrupt routine will be called. jhb had
a patch that may or may not work to fix it, but I've lost it.
This may be due to the sio probe doing something odd too.
