Add ACPI device 80860F14 with _UID 3 to the list of known devices. It
make SD card available on NUCs and Minnowboard. Previously added _UID 1
covered only eMMC devices.
Reported by: kib@
MFC after: 1 week
handler which already holds the mutex, and have sdhci_handle_card_present()
be just a tiny wrapper that does the locking for external callers.
This should fix the recursive locking panics seen on rpi3.
Reported by: Shawn Webb
Besides slots always having non-removable media, these HCIs require
a custom hardware reset sequence after power-up.
- Flesh out the support for Intel Braswell eMMC controllers further.
Apart from also requiring said reset code, the timeout clock needs to
be hardcoded to 1 MHz for these.
Both the special reset and timeout clock handlings are implemented as
global sdhci(4) quirks as the same treatment will be necessary for
Intel eMMC controllers attached via ACPI (once sdhci(4) grows such a
front-end).
- In sdhci_init_slot(), use the right capability field for determining
the announced bus width based on MMC_CAP_*_BIT_DATA.
- Correct inverted sdhci_pci_softc member comments added in r276469. [1]
Submitted by: Anton Yuzhaninov [1]
MFC after: 5 days
card presence and write protect switch detection.
A bridge driver just needs to call the setup routine in its attach(), the
teardown in its detach(), and write a couple tiny glue functions to connect
the sdhci interface functions to the new helper functions. This is not
extensively documented, but multiple examples will exist real soon.
card insert/remove events on controllers that don't implement the insert
and remove interrupts.
Bridge drivers can set a new slot option, SDHCI_NON_REMOVABLE, to indicate
non-removable media (such as eMMC). The sdhci driver will not enable
insert/remove interrupts, and sdhci_generic_get_card_present() will always
return true.
Bridge drivers can set a new quirk, SDHCI_QUIRK_POLL_CARD_PRESENT, and the
sdhci driver will not enable insert/remove interrupts, and instead will use
a callout to poll the card-present status at 5 Hz.
For bridge drivers that get notified of card insert/remove via gpio
interrupts, there is a new sdhci_handle_card_present() function they can
call from the gpio interrupt handler to inform the sdhci code of the event.
In addition to adding these new features, the existing code to debounce card
insertions was updated to use taskqueue_enqueue_timeout() instead of
scheduling a callout to do the taskqueue_enqueue(). There is also now a
comment explaining that insertion-debounce is what's going on -- it took me
a long time to realize that's what the old sdhci_card_delay() routine was
really doing. There is no functional difference between the old and new
debounce code (I hope!).
Many embedded SoC controllers that are (more or less) sdhci-compatible don't
implement card detect, and the related values in the PRESENT_STATE register
aren't useful. A bridge driver can now implement get_card_present() to read
a gpio pin or whatever else is necessary for that system.
The default implementation reads the CARD_PRESENT bit from the PRESENT_STATE
register, so existing drivers will keep working (or keep not-fully-working,
since many drivers right now can't detect card insert/remove).
Summary:
i.MX5 and PowerPC use a very similar eSDHC controller, which is also
similar to the uSDHC controller used by i.MX6. The imx_sdhci driver works
almost completely with PowerPC, with some minor tweaks.
There is one caveat with this: reset currently does not work on PowerPC, so has
been #ifdef'd out until this can be tracked down and fixed. If resets are done
the controller will timeout all data transactions. Without a reset, it appears
to work just fine.
This is part 3, following up r308186 and r308187.
Test Plan:
This has been tested on a PowerPC QorIQ P1022 board. It has not been
tested on i.MX, but no regressions are expected.
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D8407
Some controllers (namely Freescale's eSDHC, tested) will continue to assert
the card removed or card insert interrupts even after being handled. To work
around this, disable watching the interrupt that just occurred until the
opposite interrupt is triggered.
Linux has a similar change in its driver to address the same problem.
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).
(Thanks to jilles@ for providing the vital clue about the kernel linker.)
Most of these are BARs, and we allocate them in their entirety. The one outlier
in this is amdsbwd, which calls bus_set_resource() prior.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D5370 (partial)
This patch adds support for the BCM57765[2] card reader function included in
Broadcom's BCM57766 ethernet/sd3.0 controller. This controller is commonly
found in laptops and Apple hardware (MBP, iMac, etc).
The BCM57765 chipset is almost fully compatible with the SD3.0 spec, but
does not support deriving a frequency below 781KHz from its default base
clock via the standard SD3.0-configured 10-bit clock divisor.
If such a divisor is set, card identification (which requires a 400KHz
clock frequency) will time out[1].
As a work-around, I've made use of an undocumented device-specific clock
control register to switch the controller to a 63MHz clock source when
targeting clock speeds below 781KHz; the clock source is likewise switched
back to the 200MHz clock when targeting speeds greater than 781KHz.
Additionally, this patch fixes a small sdhci_pci bug; the
sdhci_pci_softc->quirks flag was not copied to the sdhci_slot, resulting in
`quirk` behavior not being applied by sdhci.c.
[1] A number of Linux/FreeBSD users have noted that bringing up the chipsets'
associated ethernet interface will allow SD cards to enumerate (slowly).
This is a controller implementation side-effect triggered by the ethernet
driver's reading of the hardware statistics registers.
[2] This may also fix card detection when using the BCM57785 chipset, but I
don't have access to the BCM57785 chipset and can't verify.
I actually snagged some BCM57785 hardware recently (2012 Retina MacBook Pro)
and can confirm that this also fixes card enumeration with the BCM57785
chipset; with the patch, I can boot off of the internal sdcard reader.
PR: kern/203385
Submitted by: Landon Fuller <landon@landonf.org>
this value at runtime.
The SD card specification says that a block write or a block erase can take
up to 250ms to complete and thus, under some circumstances, the existent 2
seconds timeout was triggering with normal usage.
This change fixes the sporadic controller timeout that happens on RPi and
RPi 2.
Discussed with: ian (some time ago)
sdhci controllers, such as the one on a Raspberry Pi, mishandle the signal
timing in high speed signaling mode, but run just fine in standard mode
with the bus running at frequencies between 25-50MHz (which shouldn't work).
This is the solution adopted by U-Boot and other OSes (linux and *BSD)
for the timeouts on Raspberry Pi boards with certain SD cards. Some
research shows that this quirk is also used on a few other boards, so the
fix is a generic quirk instead of being in the RPi-specific driver code.
This change is based on information discovered by Michal Meloun.
moving the handling of curcmd->error != 0 to the end of the interrupt
handler. Also make sdhci_finish_data() idempotent by moving the setting
of slot->data_done = 1 down past the point where the busdma buffer is
unmapped. This allows for the possibility that the finish routine can
get called from multiple places when handling errors.
to change to 0xe822, which may be persistent across reboots and, thus,
confuse other OSes. Therefore, restore the original mode and frequency
setting on detach and shutdown.
- Report Ricoh R5CE822 as such.
- According to Linux, Ricoh R5CE822 also need SDHCI_QUIRK_LOWER_FREQUENCY.
- Nuke an unused softc member.
MFC after: 3 days
TI OMAP controllers which will return the reset-in-progress bit as zero if
you read the status register too fast after setting the reset bit.
The zero is apparently from a stale snapshot of the internal state presented
in the interface register, and leads to a false indication that the reset
is complete when it either hasn't started yet or is in-progress. The
workaround is to first loop until the bit is seen as asserted, then do the
normal loop waiting to see it de-asserted.
Submitted by: Michal Meloun <meloun@miracle.cz>
- Static'ize sdhci_debug local to sdhci.c.
- Const'ify PCI device description strings.
- Nuke redundant resource ID members from sdhci_pci_softc.
- Nuke unused hw.sdhci_pci.debug tunable.
- Add support for using MSI instead of INTx, controllable via the tunable
hw.sdhci.enable_msi (defaulting to on) and tested with a RICOH R5CE823 SD
controller.
- Use NULL instead of 0 for pointers.
MFC after: 3 days
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
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
Adjust the exynos and zedboard dts files to use max-frequency (the
documented standard property) instead of clock-frequency.
Submitted by: Thomas Skibo <ThomasSkibo@sbcglobal.net>
before changing the divisor bits in the register. We were writing a zero
to the register, which clears the enable, but also cleared the divisor bits
at the same time. That's a violation of the sdhci spec, which says the
divisor can only be changed when the clock is disabled. This has worked
okay on most hardware for years, but the TI OMAP controller would misbehave
after changing the divisor improperly.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
rather than SDHCI_RESET_ALL; the latter turns off clocks and power, removing
any possibility of recovering from the error.
Also, double the timeout to 2 seconds. Despite what the SD spec says about
all transactions completing in 250ms or less, I have a card which sometimes
takes more than a second to complete a write.
If the hardware is not in a good state (like maybe clocks aren't running
because of a configuration glitch) its timeout clock may also not work
correctly, and the next command sent will hang that thread forever. The
thread in question is usually the one and only thread (at init time) or
a bio queue worker thread whose lockup will eventually lead to the whole
system locking up when it runs out of buffers.
No sd card command should take longer than 250ms. This new code establishes
a 1-second timeout to allow plenty of safety margin over that.
Normally it never needs to wait here at all; waiting is done at the end
of the prior command. When doing a crash dump, the normal interrupt
mechanism isn't used; instead the interrupt handler is called repeatedly
in a polling-like manner. This can subvert hardware-specific drivers
and lead to trying to start a new command while the previous command is
still busy on the bus. Since the SD spec says the longest a card can
take to execute any command is 250ms, use that as a timeout.
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
The sdhci spec says that if the base or timeout clock frequency in the
capabilities register is zero, the driver must obtain the frequency "from
another source." This change defines that other source to be the low-level
hardware driver, which can pre-set the frequencies in slot.max_clk and
slot.timeout_clk before calling sdhci_init_slot().
This helps with a growing number of SoCs that have sdhci base clock
frequencies that either won't fit into the range allowed by the number of
bits available in the capabilities register, or the frequency is runtime-
configurable.
