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.
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
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.
the response bits the way we do in software. While the hardware is just
doing the sensible thing rather than leaving it to the software, it's in
violation of the spec by doing so. Grrrr.
In order to use platorm backend hardware driver should
impement three methods:
- platform_start_transfer and platform_finish_transfer
to start and finish transfer
- platform_will_handle - check whether transaction is
suitable for backend. If not - driver will fall back
to PIO mode.
Submitted by: Daisuke Aoyama <aoyama at peach.ne.jp>
Approved by: ian@
- Replace divisor numbers with more descirptive names
- Properly calculate minimum frequency for SDHCI 3.0
- Properly calculate frequency for SDHCI 3.0 in mmcbr_set_clock
- Add min_freq method to sdhci_if.m and provide default
implementation. By re-implementing this method hardware
drivers can control frequency controller operates when
executing initialization sequence
sdchi encapsulates a generic SD Host Controller logic that relies on
actual hardware driver for register access.
sdhci_pci implements driver for PCI SDHC controllers using new SDHCI
interface
No kernel config modifications are required, but if you load sdhc
as a module you must switch to sdhci_pci instead.
Driver supports PCI devices with class 8 and subclass 5 according to
SD Host Controller Specification.
Update NOTES, enable module and static build.
Enable related mmc and mmcsd modules build.
Discussed on: mobile@, current@
