Commit Graph

242 Commits

Author SHA1 Message Date
Warner Losh
8e5f761422 On my Lenovo T400, a Atheros 2413 has a problem powering up
sometimes. It will power up wrong and identify itself badly:

cardbus0: <network, ethernet> at device 0.0 (no driver attached)
cardbus0: <simple comms, UART> at device 0.1 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.2 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.3 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.4 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.5 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.6 (no driver attached)
cardbus0: <old, non-VGA display device> at device 0.7 (no driver attached)

All the higher numbered functions (.2 and above) have a config space
of all 0's. This smells a bit like a special debug mode, but the
current atheros driver doesn't cope. It is unclear if this card is
just a flake, or if we're doing something wrong in the power-up
sequence.

Put a work around into the code that tests for this rather unusual
condition. If we power a CardBus device up, and the device says it is
multi-function, and any of the functions have a 0 device ID, try the
power-up sequence again.
2015-02-18 05:53:04 +00:00
Warner Losh
966e729842 Always enable I/O, memory and dma cycles. Some BIOSes don't enable
them, sometimes they are reset for power state transitions or during
whatever happens while suspended. Also, it is good practice to always
do this.
2015-01-16 06:19:52 +00:00
Warner Losh
53d673996b Move the suspsned and resume functions to the bus attachment. They
were accessing PCI config registers, which won't work for the ISA
version.
2015-01-16 06:19:39 +00:00
Warner Losh
47a66ea835 Suspend and resume were the only two functions not to follow the brdev
convention here, so fix that.
2015-01-16 06:19:24 +00:00
Warner Losh
b45c7d14d0 Back out the refactor. It turns out to cause interrupt storms on
resume sometimes (but not others). On powerup, other wierd issues show
up (sometimes the card comes up, but with really bogus pci config
space stuff. There may be more, but given my experience of historical
fussiness, stick to what works and make more minimal changes to that.
2015-01-16 06:19:08 +00:00
Warner Losh
8b91d5b008 Various interrelated fixes to make suspend / resume work better. We now
can suspend / resume and unload / load cbb and cardbus without errors
on my Lenovo T400, which wasn't possible before. Cards suspending
and resuming in the CardBus slot not yet tested.
o Enable memory cycles to the bridge early (as part of the new
  cbb_pci_bridge_init). This fixes the Bad VCC errors which were
  caused by the code accessing the device registers with this
  cleared. The suspend / resume process clears it.
o Refactor suspend / resume into bus specific code (though the ISA
  code is just stubbed). This isn't strictly necessary, but makes
  the initializaiton code more uniform and should be more bullet
  proof in the face of variant behavior among cardbus bridges.
o Fixup comments in the power-up sequence to reflect reality. These
  comments were written for one regime of power-up, but not updated
  as things were revised.
o Add a paranoid small delay (100ms) to cover noisy cards powering
  down.
o Fix some debugging prints to be easier to grep from dmesg.

Sponsored by: Netflix
2015-01-14 05:41:33 +00:00
Warner Losh
260a867f85 Fix typo pointed out by avg@ and Joerg Sonnenberger. Add a clarifying
sentence too.

Sponsored by: Netflix
2014-11-18 17:06:46 +00:00
Warner Losh
7bfa86f62a Modernize comments about BIOSes being lame since in this detail they
aren't lame, the rules changed along the way. Catch up to 1999 or so
with the new rules.
2014-11-18 01:39:21 +00:00
Warner Losh
707767a88c Remove stray empty comment. The code is adequately explained in the
block comment above, so there's nothing to add here.
2014-11-17 16:30:51 +00:00
Gavin Atkinson
7458a79a14 For reasons which are not clear, r254263 broke some PCMCIA and CardBus
bridges in strange ways, either rendering them unable to detect
insertion and removal events, or possibly unable to read from the
device behind the bridge.

This fixes at least one laptop, a Toshiba Tecra M5 with a Texas
Instruments PCxx12 (d=0x8039 v=0c104c) bridge.  The very similar
Tecra M9 has the same bridge, but worked fine without this change.

The bridge chip has no I/O port BAR, and there is nothing in the spec
to suggest I/O decoding should be enabled; however enabling it fixes
the issue.  Add an XXX comment to this effect.

Discussed with:	jhb, imp
MFC after:	2 weeks
2014-08-03 21:56:53 +00:00
Hans Petter Selasky
af3b2549c4 Pull in r267961 and r267973 again. Fix for issues reported will follow. 2014-06-28 03:56:17 +00:00
Glen Barber
37a107a407 Revert r267961, r267973:
These changes prevent sysctl(8) from returning proper output,
such as:

 1) no output from sysctl(8)
 2) erroneously returning ENOMEM with tools like truss(1)
    or uname(1)
 truss: can not get etype: Cannot allocate memory
2014-06-27 22:05:21 +00:00
Hans Petter Selasky
3da1cf1e88 Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after:	2 weeks
Sponsored by:	Mellanox Technologies
2014-06-27 16:33:43 +00:00
John Baldwin
4edef187b8 Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge
I/O windows, the default is to preserve the firmware-assigned resources.
PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
defines a PCI_RES_BUS resource type.
- Add a helper API to create top-level PCI bus resource managers for each
  PCI domain/segment.  Host-PCI bridge drivers use this API to allocate
  bus numbers from their associated domain.
- Change the PCI bus and CardBus drivers to allocate a bus resource for
  their bus number from the parent PCI bridge device.
- Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
  full range of bus numbers from secbus to subbus from their parent bridge.
  The drivers also always program their primary bus register.  The bridge
  drivers also support growing their bus range by extending the bus resource
  and updating subbus to match the larger range.
- Add support for managing PCI bus resources to the Host-PCI bridge drivers
  used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
- Define a PCI_RES_BUS resource type for amd64 and i386.

Reviewed by:	imp
MFC after:	1 month
2014-02-12 04:30:37 +00:00
John Baldwin
d53497cc2b Explicitly enable I/O and memory decoding in the bridge's command register
when activating an I/O or memory window on the CardBus bridge.

Tested by:	Olivier Cochard-Labbe <olivier@cochard.me>
Reviewed by:	imp
MFC after:	3 days
2014-01-27 19:49:52 +00:00
Scott Long
c68534f1d5 Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI
command register.  The lazy BAR allocation code in FreeBSD sometimes
disables this bit when it detects a range conflict, and will re-enable
it on demand when a driver allocates the BAR.  Thus, the bit is no longer
a reliable indication of capability, and should not be checked.  This
results in the elimination of a lot of code from drivers, and also gives
the opportunity to simplify a lot of drivers to use a helper API to set
the busmaster enable bit.

This changes fixes some recent reports of disk controllers and their
associated drives/enclosures disappearing during boot.

Submitted by:	jhb
Reviewed by:	jfv, marius, achadd, achim
MFC after:	1 day
2013-08-12 23:30:01 +00:00
Adrian Chadd
b0fa0cba65 Restore the PCI bridge configuration upon resume.
This allows my TI1510 cardbus/PCI bridge to work after a suspend/resume,
without having to unload/reload the cbb driver.

I've also tested this on stable/9.  I'll MFC it shortly.

PR:		kern/170058
Reviewed by:	jhb
MFC after:	1 day
2012-07-31 18:47:17 +00:00
Warner Losh
dbd618bf56 Some laptops have weak power controllers that cannot tolerate multiple
cards powering up at once.  Work around the easy case (multiple cards
inserted on boot) with a short sleep and a long comment.  This
improves reliability on those laptops with power hungry cards.
2012-01-27 21:49:02 +00:00
Marius Strobl
4b7ec27007 - There's no need to overwrite the default device method with the default
one. Interestingly, these are actually the default for quite some time
  (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
  since r52045) but even recently added device drivers do this unnecessarily.
  Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
  Discussed with: jhb
- Also while at it, use __FBSDID.
2011-11-22 21:28:20 +00:00
Ed Schouten
6472ac3d8a Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.
The SYSCTL_NODE macro defines a list that stores all child-elements of
that node. If there's no SYSCTL_DECL macro anywhere else, there's no
reason why it shouldn't be static.
2011-11-07 15:43:11 +00:00
Warner Losh
e6830016ad Mark the card as bad on shutdown. This means that bus_child_present
will return false on shutdown and massive spewage from usb disappears
for usb cardbus adapters.
2011-06-21 03:05:17 +00:00
Warner Losh
cf95dbae06 More expeirmentation suggests that 10ms isn't as reliable as
previously thought, but 100ms seems to be.  Likely there's a good
middle ground, but for now be conservative.
2011-06-18 03:16:51 +00:00
Warner Losh
0b96c05a7a After we get a good power signal, always wait about 10ms before
proceeding.

On boot, some laptops with certain cards in them sometimes fail on
boot, but if the card is inserted after boot it works.  Experiments
show that small delays here makes things more reliable.  It is
believed that some combinations need a little more time before the
power on the card is really stable enough to be reliable once the
power is stable in the bridge.
2011-06-18 02:25:08 +00:00
Matthew D Fleming
6dc7dc9a3e sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.
Commit the rest of the devices.
2011-01-12 19:53:56 +00:00
John Baldwin
a56fe095f0 Temporarily revert the new-bus locking for 8.0 release. It will be
reintroduced after HEAD is reopened for commits by re@.

Approved by:	re (kib), attilio
2009-08-20 19:17:53 +00:00
Attilio Rao
444b91868b Make the newbus subsystem Giant free by adding the new newbus sxlock.
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.

Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.

For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.

Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.

Bump __FreeBSD_version in order to reflect the newbus lock introduction.

Reviewed by:    ed, hps, jhb, imp, mav, scottl
No answer by:   ariff, thompsa, yongari
Tested by:      pho,
                G. Trematerra <giovanni dot trematerra at gmail dot com>,
                Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by:   Yahoo! Incorporated
Approved by:	re (ksmith)
2009-08-02 14:28:40 +00:00
Andrew Thompson
853a10a581 Revert r190676,190677
The geom and CAM changes for root_hold are the wrong solution for USB design
quirks.

Requested by:	scottl
2009-04-10 04:08:34 +00:00
Andrew Thompson
626fc9fe3d Add a how argument to root_mount_hold() so it can be passed NOWAIT and be called
in situations where sleeping isnt allowed.
2009-04-03 19:46:12 +00:00
Warner Losh
bca6fb928e Better name for this routine... it doesn't reset the card, but resets
the power to the card...
2009-03-12 06:25:30 +00:00
Warner Losh
993b1ae273 Hold off root mounting until we've gone through the loop of our thread
almost once.  After we've configured the devices that were present the
first time through, then we know that we're done.  If the device has
other devices that are deferred, then it must do a similar dance.
This catches both PC Cards and CardBus cards.
2009-02-17 02:14:04 +00:00
Warner Losh
a620f9a577 Correct signatures to match kobj function definitions. 2009-02-04 21:11:31 +00:00
Warner Losh
d0493c85a6 Update to the interrupt handling code:
o Try to be smarter about reading the ExCA CSC register.  Now, we only
  do it for 16-bit cards.  Add some experimental code to treat it like
  a power interrupt, but I'm not 100% sure that I like it.  It may be
  removed upon further testing.  It seemed to help in one test case, but
  the evidence may be inconclusive.  This may be beneficial for cleaning up
  exca_reset and exca_wait_ready.
o Check for CSTS events on the socket event register.  We ask for it when
  we're powering up a card, but I don't think we're otherwise using
  it.  Just ACK the interrupt for now.  In theory, we can use it
  instead of the busy wait we do in cbb_cardbus_reset.  More research
  is necessary to see if we can optimize things there when we're
  waiting for the DEVVENDOR register to become valid.
o Rework the comments a bit.  Minor tidying up.  Etc.
2008-12-11 06:27:18 +00:00
Warner Losh
f2323a477f Minor tweaks to some of the comments. Also, add a XXX wondering if we
need to frob the 16-bit EXCA registers during the new interrupt-driven
power-up sequence.
2008-12-07 22:49:47 +00:00
Warner Losh
a5d1eba6cf Use '0' rather than PZERO to not change the priority that I'm waiting
at.  I don't think this will make a huge difference, but I have
received a report of a interrupt storm on one 16-bit card that this
might fix (chances are it won't, since I think that we may need to
check both the CBB registers for the 16-bit card as well as the PCIC
registers for power state change).

Submitted by:	jhb@
2008-12-07 18:34:27 +00:00
Warner Losh
3e7d0bebac Use atomic_add_int rather than a simple ++ to ensure no cache races if
the power interrupt and init code waiting for the interrupt are
running on different CPUs.  I haven't seen this make any real
difference, but I've also had some reports of odd behavior I can't
otherwise explain.  It is an infrequent operation, and certainly
wouldn't hurt.
2008-12-07 18:32:09 +00:00
Warner Losh
5b9ee137aa Move to using filter for the change interrupts. Also rework the power
interrupt code to be more robust.  I've been running these changes for
over a year...  With these changes, I don't see the ath card going
into reset like the code in the tree.
2008-12-05 05:20:08 +00:00
Warner Losh
ca446278b1 Minor style nit. 2008-12-05 04:48:04 +00:00
Warner Losh
f40b0e2e97 Augment comments, and move things around a smidge. 2008-12-05 04:46:26 +00:00
Warner Losh
414f7ec8bd Implement a method described in NetBSD PR 36652 for coping with the
BAD VCC bit.
2008-12-05 04:43:25 +00:00
Warner Losh
a3f223e26a Return BUS_PROBE_GENERIC rather BUS_PROBE_DEFAULT for generic CBB we match.
Reviewed by:	jhb@
2008-10-02 22:50:11 +00:00
Warner Losh
6e31e5ebde Don't forget to match on a CLASS of PCIC_BRIDGE as well as subclass
PCIS_BRIDGE_CARDBUS.  Otherwise, we may hit a few false positives....
2008-10-02 06:29:45 +00:00
Warner Losh
8e6604f8d5 Read the config space of the child, not the bridge, to determine when
the child is out of reset... <blush>
2008-08-10 09:55:14 +00:00
Warner Losh
d1a8ac92a9 fix typo
Submitted by:	N.J. Mann
2008-08-09 17:29:36 +00:00
Warner Losh
e6501bf131 It turns out that checking the first DWORD register is more reliable
on a variety of cards.  Adjust the comments accordingly to match the
code.  Even if the vendor chose 0xffff for the device ID, the vendor
ID can't be 0xffff, so the test is still valid from a standards
perspective.
2008-08-09 15:55:10 +00:00
Warner Losh
1b146a73ee After some intial testing, there are even slower cards than the ones
that I have.  Wait up to 1.1s for the card to become ready.  Document
what the standards say, and use that to justify the behavior in the
code: PCI standard says that a card must respond to configuration
cycles within 2^25 cycles after reset goes high, which is
approximately 1s.  Therefore, give cards a little break and wait for
up to 1.1s for VENDOR to become valid.  Only look at the vendor part
of the ID, since only it can't be 0xffff (although in practice
vendor/device will always be != 0xfffffffff).  Include detailed
pointers to standards so epople understand why we're doing what we're
doing and why it just might be OK.  Make it clear in the timeout
message that it is just a warning, sinc we try to soldier on as best
we can anyway.

This should eliminate an error message that r181453 produced on
certain Atheros cards.
2008-08-09 07:41:18 +00:00
Warner Losh
bfd58cce84 Rather than waiting a fixed amount of time, which might not be enough
and also holds things up, check every 20ms to see if we can read the
vendor of device 0.0.  It will be 0xffffffff until the card is out of
reset.  Always wait at least 20ms, for safety.

I think this is a better fix to the reset problem.  However, I did it
as a separate commit in case something bad happens, people can roll
back to the commit before this one to see if that gives them reliable
behavior.  I don't have FreeBSD up on enough machines to do exhaustive
testing on all known bridges...
2008-08-09 04:08:36 +00:00
Warner Losh
ae438af62d While most bridges can bring a card out of reset in 20ms, there are
some bridge + card combinations that take longer for reasons unknown.
Adjust the timeout to be 100ms on all !RICOH bridges, but leave RICOH
at 400ms.  The 400ms is "lore" from other open source projects, and
I've never see my ricoh bridge chips take this long.  Maybe it is the
same thing?  Maybe a bit should be read instead of a hard-wired pause?

After this adjustment, a few cards that I'd insert and get only:
	cbb0: card_power: 3V
	cbb0: card_power: 0V
with full debugging enabled would actually try to attach.

Reported by:	sam@ (I think)
MFC after:	3 days
2008-08-09 03:37:12 +00:00
Julian Elischer
3745c395ec Rename the kthread_xxx (e.g. kthread_create()) calls
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.

I'd LOVE to do this rename in 7.0  so that we can eventually MFC the
new kthread_xxx() calls.
2007-10-20 23:23:23 +00:00
Marius Strobl
55aaf894e8 Make the PCI code aware of PCI domains (aka PCI segments) so we can
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.

Suggested by:	jhb
Reviewed by:	grehan, jhb, marcel
Approved by:	re (kensmith), jhb (PCI maintainer hat)
2007-09-30 11:05:18 +00:00
Warner Losh
6e878bc765 Migrate from setting a CARD_OK flag in a shared word, to setting its
own entry in the softc.  This should allow more of cbb_pci_intr() to
migrate to a new cbb_pci_filt() so that we don't have to run cbb's ISR
in almost every case we get an interrupt.  We can't just move
cbb_pci_intr into cbb_pci_filt because it does things that aren't safe
to do from a fast interrupt handler, err I mean from a filter.  This is
an important first step.

# I wonder if I need to make cardok volatile or not.
2007-06-04 05:59:44 +00:00