config space that I'm aware of) work. I'm committing this from such
a machine.
Remove warning about I/O based bridges. Warn users that the PCI routing
of interrupts still doesn't work for these cards.
o For TI PCI-1130, you need to set bit 5 of register 91 if you want
ANY pci interrupts. Then set bits 3 and/or 4 as appropriate. This
will fix those people with 1030, 1130 and 1131 in their machines
trying to do PCI interrupts.
o Fix case where we were trying to automatically fail back to ISA
interrupt routing. We were dereferencing a NULL pointer. This
was true of ANY chipset.
o The bus_setup_intr method needs to be pcic_setup_intr so that "FAST"
interrupts fail on PCI case (modems act flakey if we don't force
them to fall back to normal interrupts). Also needed so that the
proper ISA IRQ can be set in the ExCA register. This fixes the
people whose ISA routing was failing[*].
o When we find a generic yenta/pccard bridge, go ahead and print its
vendor ID in boot verbose.
Machine with theses symptoms and a serial console by: jedgar
[*] Looks like my pc98 machine has some interrupt source on IRQ 15
that gave about 30 interrupts per second, which masked this problem on
my PC-9821Nr15.
interrupt for the CSC interrupt, then we revert to ISA. If we didn't
have an interrupt set up with hw.pcic.irq, then do polling.
Also, don't complain about ignoring function 1 for any devices except
pcic devices. This would normally only show up if someone set
hw.pcic.ignore_function_1=1.
MFC: as soon as I can test it on some troublesome laptops.
explain the subtle side effects that are going to happen and why we go
ahead and ack the interrupt source. This stuff is tricky to get
right.
Also, emperical tests have shown that doing a shutdown in attach to be
ineffectual, so remove it from there. Analysis of the code paths
shows that nearly identical writes to these registers happen in later
parts of the code. The hanging problem on thinkpads when we change
the interrupt routing type is something else.
shutdown and also before we get going with the device initialization.
This may fix the hangs some people are seeing on warmboot. It appears
that some machines will reset the cardbus bridge on boot, while others
don't. So we turn off the card, and ack the interrupts (which likely
is a nop in the shutdown case since we're still fielding interrupts).
This should turn off the interrupts.
Since I don't have hardware that hangs on reboot, I'm committing this
without testing that aspect of the patch (it causes no harm on my
Dell).
initialization structure. Warn the user for those chipsets that
aren't yet customized that they might not work. Second, try to power
off the slot on attach and ack the interrupts. I don't know, but this
might solve the hangs that people will see on Thinkpads if they set
hw.pcic.init_routing=1.
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.
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.
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.
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).
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.
information until the problems can be tracked down. Right now these
are unconditional, but later it will be hidden behind a boot verbose.
Also, if there are no events listed in the event mask, return right
away. Specifically avoid writing back interrupt acks in this case.
Print type of pci bridge we find.
Force the IRQ of pci bridges upon all its children.
Allocate the resources on behalf of the bridge when we're testing to see if
they exist.
This should help people who don't read updating instructions very well.
This patch started out with an idea from Shigeru Yamamoto-san in -current.
higher chips. Treat it as if it were a 113x. This is correct as far
as 16-bit cards go, at least how we're using it.
# It appears that my TI-1031 based pci card that YAMAMOTO shigeru-san gave
# me on my trip to Japan now works.
elected to do this in the probe rather than the attach so that we don't
disturb things which this might reset. different cards have different
quirks, according to their datasheets.
This should fix the "I booted in windows and rebooted to FreeBSD and
now things don't work" problem.
PR: 4847, 20670
card bus bridges.
We now always use pci interrupts for pci cards. This will allow us to
more easily configure things. You must change your IRQ lines in
/etc/pccard.conf to match what we've probed. I'm not sure the right
way to deal with this right now.
Development of pci pcmcia has been funded by Monzoon Networks AG. I
am grateful for their generosity.
o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_PCMCIA and
programming interface is 0, assume that it is a generic PCMCIA PCI
chip we can program. I don't think there are any of these that
we don't know about, but you never know.
o If the class is PCIC_BRIDGE, subclass is PCIS_BRIDGE_CARDBUS and
programming interface is 0, assume that it is a YENTA cardbus bridge
that we know how to cope with. There are likely some cardbus bridges
that haven't it made it in here yet.
of the pcic class of devices. Go ahead and move it to the "usual"
place. I say "usual" in quotes since it isn't exactly right (not in
dev/blah), but it is closer than before.
