| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ok mglocker@
|
|
|
|
| |
ok patrick@
|
|
|
|
|
|
|
| |
mode, so switch from 1-bit to 4-bit bus width if the host controller
supports it.
ok kettenis@
|
|
|
|
|
|
|
| |
has to support for MMC cards prior to reading the extended registers.
We already do this for SD cards. Fixes eMMC support on the i.MX8M.
Tested by and ok kettenis@
|
|
|
|
|
|
|
|
| |
sdmmc chipset driver, currently only implemented in sdhc(4), but
mostly uses the regular path. sdhc(4) also needed the ability to
perform IO while cold.
ok deraadt@
|
|
|
|
| |
ok dhill
|
|
|
|
|
|
| |
card. Data transfers don't seem to work on the Realtek RTS5229 Card Reader
if the clock frequency is too low, and reading the SCR requires a data
transfer.
|
| |
|
|
|
|
|
| |
transfer rates to and from the card. In practice the improvement will be
smaller, but I am seeing serious improvement in the read speeds.
|
|
|
|
|
|
|
| |
sdhc(4) controllers that support it. Mostly from NetBSD.
This makes the raw transfer rate of the eMMC on the Lenovo Ideacentre
Stick 300 go up to 40 MB/s.
|
|
|
|
| |
sure it has witched before changing the bus clock speed.
|
|
|
|
|
|
| |
controller. Use this to switch SD cards to a 4-bit bus if they support it.
ok deraadt@, jsg@
|
|
|
|
|
|
|
|
|
|
|
|
| |
support ADMA2. The older SDMA mode has too many limitations to be really
usable. Gives us only moderate speed improvements, bus reduces the CPU load
considerably. We will reap the full benefits once we implement wider bus
widths and high speed modes.
There is a remining issue with simultanious use of eMMC and external SD card
on (some) Intel Bay Trail hardware. Still under investigation.
ok patrick@, stsp@, deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
| |
boards with Micron eMMC to work. The Micron eMMC seems to adhere to the
spec which states:
"If there is no indication by a host to a memory that the host is
capable of handling sector type of addressing the higher than 2GB of
density of memory will change its state to Inactive (similarly to a sit-
uation in which there is no common voltage range to work with)"
From Ian Sutton with feedback from uwe@
|
|
|
|
|
| |
otherwise the value would be uninitialised in the unlikely
case of being called with length 0.
|
|
|
|
|
|
| |
Based on a diff by Cedric Tessier, nezetic at gmail dot com, thanks!
Discussed with and ok jsg@
|
|
|
|
| |
after discussions with beck deraadt kettenis.
|
|
|
|
|
|
|
|
|
| |
This capability force the sdmmc stack to only issue
single blocks transfers.
tested by rapha@ and I on ommmc(4).
tested by rapha@ on pxammc(4).
ok rapha@
|
|
|
|
|
|
|
|
| |
Heavily based on netbsd.
Tested by dlg@, bcallah@ (sdhc), stsp@ (rstx) and me (ommmc).
ok patrick@
|
|
|
|
|
|
|
| |
and with this, my adventure in sdmmc-land is over
bikeshed is still banana-shaped
ok oga@
|
|
|
|
|
|
| |
making DEVNAME() usage a lot more consistent.
ok krw@
|
|
|
|
|
| |
back to the card. fixes a problem where the controller supported lower voltages
than the card. With variable name change requested miod, ok miod@ krw@
|
|
|
|
| |
ok deraadt@, miod@
|
|
|
|
|
|
|
|
|
| |
In snaps for a while.
Originally hacked on phessler@'s couch.
Testing by many, input from jsg@
"I'm tired of seeing the Ms" deraadt@
|
|
|
|
|
|
|
|
| |
transfer with one command. Build on this and the recent minphys() changes
in the sdmmc layer to crank transfers at the maximum possible size instead
of a sad DEV_BSIZE.
Depending on your controller, this can speed up sdmmc I/O up to 2.5 times.
|
|
|
|
|
|
|
| |
Thanks to everyone who tested in particular jsing@ who found several
problems in the initial diffs.
ok dlg@ jsing@ miod@
|
|
|
|
| |
crashes the moment a card is plugged in.
|
|
|
|
|
|
|
| |
Add SDMMC_ASSERT_LOCKED(), replacing many locking calls, and sprinkling
the assertion to make sure that future changes don't catch us out
"please commit" uwe@
|
|
|
|
| |
controllers don't. Put in a temporary hack for pxammc on Zaurus.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trying to get MMC commands through to the SD/MMC host controller via the
emulated SCSI layer. This is achieved by ensuring exclusive access to
the host controller for one process during any MMC command and during a
sequence of commands at the sdmmc(4) layer.
While at it, the command processing thread has been moved to sdmmc(4),
so as to simplify the implementation of future host controller drivers.
This should also pave the way for further cleanup of the code and for
new drivers.
Minor cleanups are included in this commit, as well.
|
|
|
|
|
| |
- Always set the "SDIO function 0" pointer to something, even if it is
a memory-only card to avoid further special cases in SDIO drivers.
|
| |
|
| |
|
|
generic bus layer, and SCSI emulation for SD/MMC memory cards.
|