This allows one to select the method of 3.3V card detection from the
three possible choices (none (0), the "6710 way" (1) and the "6729
way" (2)). The default is the 6710 way, since it works in the most
cases. The datasheets for the 6722 suggest that the '29 way is more
correct, but experience has shown this method to cause some laptops to
hang solid. See source code for details until I update the man page.
Submitted by: shibata-san (chiharu shibata <chi@bd.mbn.or.jp>)
o It needs to have pcic_isa_intr intrrupt handler
o for pci interrupts, in the func interrupt handler it needs to check the isa
registers rather than the pci ones for card present.
o better commentary for some of the strangeness of the 6729 on pci
o fix some crunchy comments to better reflect reality.
With this I almost have the WL200 working, but an interrupt storm
after attach is causing problems for reasons unknown. This code
doesn't seem to break the normal clpd6729 case, and I'd like others
with 6729 cards to try to test it (there were some that were used for
external pccard slots in pci only systems).
o Add preliminary support for Cirrus Logic CL-PD6729 using PCI
interrupts. To use it you you need to set hw.pcic.pd6729_intr_path
to 2. This is allow us to still default to ISA intrrupt path for
this part (which is found much more often in laptops using ISA IRQs).
But some PCI cards have this part on them and this should allow them
to be used. It is untested on PCI, but it seems to not break the ISA
case.
o Better sysctl descriptions (I hope).
that's binary compatible for -stable. While binary compatibility doesn't
matter much in -current, it is critical for -stable. This change requires
pccardd/pccardc to be recompiled.
bridges in modern hardware (that hardware w/ lots of RAM). Raise the
address from 0x44000000 to 0x88000000 to match what we do with
NEWCARD. However, this really should be done in the pci layer.
o ToPIC is happy with two cards now, even when the two cards are
modems.
o Fix (all?) hangs on boot when power is applied to the card. I
suspect that this will make the Ricoh bridges happier and also
make a lot of VAIO owners happy (confirm to me in private email
please :-).
o All Cardbus bridges should now support 3.3V, X.XV and Y.YV cards,
to the extent that the underlying hardware supports such cards.
(X.X and Y.Y haven't been assigned values yet :-).
o Better 3.3V support for Ricoh ISA bridges.
How:
o Don't mess with the power register when scanning the cards. It
is unnecessary and causes BADVcc conditions on many chipsets. These
in turn can cause an interrupt storm.
o Make pcic_disable reset the slot's voltage.
o Move initializing voltage for the slot until after it has been
disabled.
o Fix a lot of issues with the pcic_cardbus_power routine. We
now properly enable the card and take it out of reset after
a power change.
o When detecting the card's voltage, if we're in a BadVcc state,
direct the bridge to rescan the card for what it supports.
(we might need to in the future set the power register to 0
before doing this).
o Don't preserve CLKSTOP. need to revisit this.
o Better support for Ricoh ISA bridges for 3.3V cards.
o Don't write to PCIC_POWER directly as offten, but instead go
through the pcic_power interface.
o All cardbus bridges now default to use cardbus power control.
o Add misc register definitions.
o remove some (now) bogus comments.
Extra Special Thanks To: Scott Lamber for his kind and generous loan
of a Toshiba laptop with a ToPIC 100 in it for my use.
general cleanup of the API. The entire API now consists of two functions
similar to the pre-KSE API. The suser() function takes a thread pointer
as its only argument. The td_ucred member of this thread must be valid
so the only valid thread pointers are curthread and a few kernel threads
such as thread0. The suser_cred() function takes a pointer to a struct
ucred as its first argument and an integer flag as its second argument.
The flag is currently only used for the PRISON_ROOT flag.
Discussed on: smp@
detect 3.3V cards for the 6710 and another method for the 6722. This
latter method is also how the 6729/6730 is supposed to detect 3.3V
cards. This method works great on my Fujitsu Stylistic 500. Sadly,
it appears that not all laptop makers are as detail oriented as the
folks that made the Stylistic. IBM Thinkpad 701C and AST Asentia 810N
both hang hard when the 6729 method is used, but at least the thinkpad
works when the 6710 method is used. The failure mode appears to be any
access to the memory that we've mapped the CIS in causes the machine to
hang until you eject the card. The Thinkpad, at least, works with this
change, and it doesn't break my Stylistic.
MFC after: 4 days
value (-1) in lue of 50 (which assumes a 5.0V card). The rest of the
pccard system doesn't detect the proper voltage for the card, so we have
to do it on powerup. Many (all?) 3.3V cards can tolerate 5.0V for reading
the CIS, but may fail to operate properly when so powered.
Idea from: Chiharu Shibata-san <chi@bd.mbn.or.jp> in bsd-nomads:15867
o Bite the bullet and create controller types for the 6729 and also for
the 673x. Rename the 672x to 6722.
o Define minimal extended register info (just register 0xa for reading VS[12]).
# I think the last version may have broken 673x controllers, but this should
# fix them.
Tested on the 6722, but not the 6729.
Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866
on my CL-PD6722, but won't work on the CL-PD6729. The latter two need
more sophisticated detection of 3.3V cards than I'm up to at the
moment. Also, only a few of the ISA chipsets that support 3.3V will
likely work at the moment.
It appears that for 3.3V cards we must detect them and adjust the
pwr.vcc value from 50 to 33. Give a strong hint to automatically
power up the card for PD_POWER cards.
This makes my SMC 2602W (the 3.3V version of the 2632W) work on my
Fujitsu Stylistic 500.
SMC 3.3V card donated by: Ryan Losh
Thanks to: bsd-nomads for reviews of past 3.3V code
should also whine if the old pccardd is used, but that's a little
harder than it sounds.
This also has the effect of fixing a typo that was in the last
version I committed.
this accross suspend/resume events and this was causing the dreaded false
positive hit on my "static bug" test.
Note: the PCI bus code should do this for us.
Note2: We don't do the same for I/O based pci devices since it is
more code and doesn't appear to be necessary.
Submitted by: Toshiyuki Kawashima-san <tos@fa2.so-net.ne.jp>
Obtained from: bsd-nomads:16012
with the pccards deactivated. This can work around some problems in
pccard system, but is also for people that want to explicitly turn on
cards after boot rather that at boot.
MFC after: 7 days
Submitted by: iwasaki-san
Reviewed by: ume-san, shiba-san
for initializing the parts. Since I don't have any of these parts in
any of my working laptops, I'm committing this to allow people to test
it. Will MFC when I receive reports of it working.
o Move initialization of the slot bst and bsh to inside the for loop.
o move sc there as well.
o Remove debug printf that prints the ID of the first slot twice.
o Use the sp for the relevant slot in getb, rather than for the 0th slot.
again? That NEVER works!" "This time for sure!"
Minor overhaul of how we do interrupts for the pci interrupt routing
case to cope with card ejection better (read: make it not hand on so
many cards):
o Reintroduce func_intr and func_arg and use the to store the
interrupt handler to call.
o Create a pcic_pci_func_intr to call the real interrupt handler
iff the card hasn't been ejected.
o Remove some checks in pcic_setup_intr now that it is used
exclusively for isa routed interrupts.
o Defer the eject event until later too, but make sure we can't
do any client driver ISR calling in the interrum.
o Add some simple code to make sure that we don't attach more
than one child. This should fix pccardd starting twice
problem (ala single user -> multi-user when you started pccardd
by hand in SU).
MFC: after jkh thinks I've put the crack pipe away.
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
message. Some scsi devices have rather elaberate flags, and it is
hard to know which ones were specified in pccard.conf when debug
information only includes the dmesg.
