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.
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.
told to use IRQ 6, progam the pcic to use irq 7 instead. Evidentally,
at least some of the cards are wired this way. If you want to use irq
6, configure it. All the mapping is done just before we set the
interrupt registers. See [FreeBSD98-testers 5064] for details.
Added commentary about valid interrupts on some CBUS pc98 CL PD6722
based cards.
Submitted by: Hiroshi TSUKADA-san <hiroshi@kiwi.ne.jp>
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.
for card change interrupts is different than the pci stuff that's
coming soon. Set the management irq in different ways. If
pci_parallel interrutp routing, then use the PCI way of getting
interrupts. Move polling mode into pcic_isa since when we're routing
via pci polling doesn't work because many bridges (systems hang solid).
If we're routing interrupts via pci, they can be shared, so flag them
as such.
Note, this doesn't actually change anything since the pci attachment
isn't quite ready to be committed.
csc_route and func_route to hold the way that each interrupt is
routed. csc is Card Status Change in the datasheets and standard, but
is called "Management Interrupt" in FreeBSDese. There are three types
of interrupt routing: ISA parallel, PCI parallel and ISA serial (some
chipsets support other types as well, but I don't plan on supporting
them).
When we try to allocate an interrupt, and the type for that interrupt
is pci_parallel, allow it to be shared by oring in RF_SHAREABLE to the
flags argument. Introduce pcic_alloc_resource to allow this to
happen.
interrupts on other buses. Right now it isn't used, but will be for
the pci attachment.
# Add copyright by me for this year since I've changed so much.
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.
pcic_{get,put}b_io. There are some pci bridges (the CL-PD6729 and
maybe others) that do not have memory mapped registers, so we'll need
these in both places. Declare them in pcicvar.h.
have a slightly different 3.3V support than the other clones, so
compensate as best we can. Note: 3.3V support is untested since I do
not have any 3.3V cards that I know of to test it with.
Work through the various power commands and convert them from a "is
this a foo controller or a foo' controller or a foo''' controller" to
a cabability based scheme. We have bits in the softc that tell us
what kind of power control scheme the controller uses, rather than
relying on being able to enumerate them all. Cardbus bridges are
numerous, but nearly all implement the i82365sl-DF scheme (well, a few
implement cirrus CL-PD67xx, but those were made by Cirrus Logic!).
Add a pointer back to the softc in each pcic_slot so we can access
these flags.
Add comments that talk about the issues here. Also note in passing
that there are two differ Vpp schemes in use and that we may need to
adjust the code to deal with both of them. Note why it usually works
now.
We have 5 power management modes right now: KING, AB, DF, PD and VG.
AB is for the i82365 stpes A, B and C. DF is for step DF. PD is the
cirrus logic extensions for 3.3V while VG is the VADEM extensions for
3.3V. KING is for the IBM KING controller found on some old cards.
# I'm looking for one of those old cards or a laptop that has the KING
# bridge in it.
We have to still cheat and treat the AB parts like the DF parts
because pci isn't here yet. As far as I can tell, this is harmless
for actual old parts and necessary to work with 3.3V cards in some
laptops.
This almost eliminates all tests for controller in the code. There
are still a few unrelated to power that need taming as well.
o Introduce flags word to the softc. This will be used to control various
aspects of the driver. Right now there are two bits defined, PCIC_IO_MAPPED
and PCIC_MEM_MAPPED. One for ISA cards that are I/O mapped, the other is
for PCI cards that are memory mapped. Only the ISA side is implemented
with this commit.
o Introduce a pcic_dealloc which will cleanly dealloc resources used. Right
now it is only supported when called from probe/attach.
o Keep track of resources allocated in the pcic_softc.
o move pcictimeout_ch to the softc so we can support multiple devices
in polling mode.
o In ISA probe, set PCIC_IO_MAPPED.
o Introduce and compute the slot mask. This will be used later when
we expand the number of slots on ISA from 2 to 4. In such a case, we
appear to have to use polling mode otherwise we get two different cards
trying to drive the same interrupt line. I don't have hardware to
test this configuration, so I'll stop here.
o Add defines for the VS[12]# bits in register 0x16.
o Add comment about what we're doing reading register 0x16 (PCIC_CDGC)
in the DF case.
o Check bit VS1# rather than a random bit I was checking due to a bogus
transcrition on my part from nakagawa-san's article.
o Add note about IBM KING and 3.3V operation from information larned from
wildboard.
things to get 3.3V. It appears that some cardbus chipsets have id
registers that say they are C step parts, but they really support the
DF step 3.3V functionality.
# Need to verify that IBM KING is handled properly since the MISC1
# register is really a cirrus logic only register.
82C146. The Intel i82365SL-DF supports 3.3V cards. The Step A/B/C
parts do not appear to support this. This is hard to know for sure
since it was deduced from "compatible" parts' data sheets and the
article mentioned below.
Rework the VLSI detection to be a little nicer and not depend on
scanning cards twice. This would allow bad VLSI cards to coexist with
a good intel card, for example. We now detect i82365SL-DF cards where
before we'd detect a VLSI. For the most part, this is good, but we
run a small chance of detecting a single slot 82C146 as a i82365SL-DF.
Since I can't find a datasheet for the 82c146, I don't know if this is
a problem or not.
This work is based on an excellent article, in Japanese, by NAKAGAWA,
Yoshihisa-san that appeared in FreeBSD Press Number 4. He provided a
patch against PAO3 in his article. Since the pcic.c code has changed
some since then, I've gone ahead and cleaned up his patch somewhat and
changed how the code detects the buggy '146 cards.
I also removed the comment asking if there were other cards that
matched the 82C146 since we found one and additional information isn't
necessary.
soon attach directly to pcic rather than the kludge pci-pcic device we
have now.
In some ways, this is similar to the work PAO3 did to try to support
cardbus bridges. In some ways different. This and future commits
will be taking from the spirit of many of those changes. pcicvar.h is
completely different from the pcicvar.h that appeared in PAO3, but
similar in concept.
controller found in many of the early NOTE98 machines that were
produced. This controller is completely unlike the intel 82365, so
I've separated it out from the main pcic driver.
have bad grounding characteristics which allow small static discharges
(or sunspots, we're not 100% sure which) to reach the bridge chip.
This causes the bridge chip to wedge/reset itself. There's no known
cure short of rebooting.
The bug manifests itself by the STAT_CHG return 0xff when read. This
is impossible because the upper bits are reserved (and therefore
zero). In addition, some of the lower bits are one only for memory
cards, which OLDCARD doesn't support, so if they are set, something
seriously foobar'd is going on.
So far we've seen this in exactly one brand of pcmcia <-> isa bridge
which plug and play identifies only as "VIA PCMCIA CARD". This card
just has buffers on the isa card and the actual bridge chip on the
remote slot, which is connected by long ribbon cables. We think this
long cable run, coupled with the lack of coupling capacitors is a
major reason why it is so static sensitive while its bretheren aren't.
Work Supported by: Timing Solutions, Inc.
MFC After: 3 days
For memory for the pccard attribute/common memory mapping allocate on
the pccard. For other allocations, use whatever is the parent of this
device. There's no doubt other issues lurking, but this should make
things closer to being independent.
the resource activation if we're dealing with our grandchild.
Otherwise, we run into two problems. One, if the pccard layer wanted
to allocate and activate something, we'd wind up trying to do the
wrong thing twice: the ivars are wrong and we don't want the bridge to
map the resource to the slot. If we're more than a grandchild, then
who knows what kind of ivar is present. In either of these cases, we
just pass it up the food chain.
when PC98 is defined. This is in perparation for a mecia driver
separate from pcic, assuming that all goes well with that effort.
MECIA_SUPPORT won't be removed until after that support is working.
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.
softc.
o Store pointers to softc in dev_t in si_drv1.
o Change 'kludge version' to 'classic version' since things are getting less
kludgy.
o Minor code shuffling so that we probe and attach the pccard slots.
o Minor style(9) changes.
machdep.pccard.pcic_mem_start
machdep.pccard.pcic_mem_end
and default the range to IOM_BEGIN/IOM_END.
This may prove useful to if_ray users (and others) on more modern
hardware that maps BIOS stuff into 0xd000-0xdffff.
MFC: after 1 week
Approved by: imp
chip to the one that the Japanese use. Now we get insert/remove
events on my PC-9821Ne. More work in bus space is needed to make
drivers work.
MFC after: 3 days
layer. This fixes an ordering problem that would cause the ISR for
the device to run with now power applied to the device. Most cards
failed to deal with this gracefully, and thus would hang on card
eject.
The power down event, for those keeping score, is what causes the
interrupt for the card.
Many folks in the Japanese nomads list have reported this, so I'll be
MFCing quickly for their benefit.
Submitted by: Masayuki FUKUI
MFC after: 2 days
means that the pcic98 functionality might now work (I've tested it on
my pcic machine, but not the pcic98). Since these functions are
rarely called, it is unlikely that this will have a measurable impact
on performance.
FreeBSD. This code doesn't work just yet, but does compile. We need
to start indirecting via the cinfo pointers, rather than directly
calling pcic_*. There may be other issues as well, but you gotta
start somewhere.
Obtained from: PAO3
parts. This is based on the newcard code that turns it off :-). We
can now reboot after NEWCARD or Windows and have OLDCARD work. Add
support for the RL5C466 while I'm at it.
Treat TI1031 the same as the CLPD6832. It doesn't work yet, but sucks
less than it did before.
Also add a few #defines for other changes in the pipe.
region for CIS reading" problem:
Use bus_alloc_resource to get the memory that we'll be using. Also
has the benefit of doing usage checking as well. This gets rid of the
ugly kludge that we had before for mapping pmem to vmem.
Second, move PIOCSRESOURCE to its own routine and make it conform more
to style(9) in the process.
pccard in the kernel for those drivers with pccard attachments. This
makes the compat layer a little larger by introducing some inlines,
but should almost make it possible to have independent attachments.
The pccard_match function are the only one left, which I will take
care of shortly.
routine instead of pccard_event(). This avoids spurious extra calls
to pccard_insert_beep() at insert or remove time which could occur
due to noise on the card-present lines.
Clean up some code in pccard_beep.c; we were depending on the order
of evaluation of function arguments, which is undefined in C. Also,
use `0' rather than `NULL' for integer values.
Reviewed by: sanpei, imp
o Attempt to disable the slot when we detect that there are problems with
it in our ISR. This should make polling mode work better for more cards,
but more work may be needed. This "disabling" sets the card interrupt
register to 0. This worked for me for lots of tests in polling mode.
o Now that I've found datasheets, fix a boatload of magic numbers in the
source to make it easier to understand.
o Use a table of names rather than a big case statement.
o Cull a few of the "unused" controller types that we map to other times
that were a vestiage of PAO code that we never merged in the same way.
o Enforce legal IRQs. You are no longer allowed to try to use IRQs that
will fail on all known ISA/PCI <-> PCMCIA bridges. The bridges do not
have pins for these illegal interrupts, and all of them are listed as
reserved and/or illegeal in the datasheets depending on which one you
look at.
o Add comments about how IBM-AT based computers and NEC PC-98 based computers
map these interrupts and which ones are valid.
o Always clear the bit that steers the management interrupt either to the
value listed in the PCIC_STAT_INT register. I've seen this bit get set
on suspend/resume and after windows boot, and it does't hurt to clear it.
NOTE: this might mean we can share this interrupt in the future.
one memory map. The memory window for the PCIC is identifed by the resource id
for NEWSBUS drivers. pccardd always uses window 0 and rid 0 when setting maps
up. This fix does not affect pccardd's handling of common memory for ed cards.
Reviewed by: imp
o Fix OLDCARD to use the new interface.
o Rename the offsetp argument to deltap to more closely reflect what it
is returning (it returns the delta from the requested value to the actual
value).
o Remove duplicate $FreeBSD$ in pccbb.c
o Allow deltap to be NULL.
o Convert new isa pcic driver and add XXX comments that this function isn't
actually implemented there (which means that NEWCARD pccard stuff won't
work there until it is).
o Revert attempts to make old inferface work in NEWCARD.
Subitted by: peter (Parts of the new version code)
