| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
the driver attached to an SDIO card always holds the lock and only
releases it once it detaches. Now with that in mind, some time ago
sdmmc_io_function_disable() and sdmmc_io_function_ready() were changed
to only assert the write lock and not take it, but not all of the tree
was converted. Change sdmmc_io_function_enable() as well, and remove
the enter/exit dance in the interrupt code. Apparently there is no
SDIO driver yet/anymore which would trigger those issues.
ok kettenis@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FullMAC, in comparison to SoftMAC, does most WiFi handling in the
firmware that's running on the controller. This means we have to
work around the net80211 stack while still implementing all the
WiFi interfaces to userland.
This driver is still in early development. So far it can connect
to open WiFis over the USB bus. SDIO and PCIe support, for devices
like the Raspberry Pi 3 or the Macbooks, is not yet implemented.
Also mbufs on the transmit path leak and are not yet freed.
ok stsp@
|
|
|
|
| |
ok visa@
|
|
|
|
|
|
|
|
|
|
| |
the Rockchip RK3399.
- Make it possible to override sdhc_signal_voltage().
- Make it possible to disable double-data rate modes.
ok patrick@
|
|
|
|
| |
ok visa
|
| |
|
|
|
|
| |
ok dhill
|
|
|
|
|
|
| |
struct proc to struct process.
ok deraadt@ kettenis@
|
|
|
|
|
| |
succeed. No downside in the bottom part of the driver.
ok dlg krw
|
|
|
|
| |
Tested and ok kettenis
|
|
|
|
|
|
|
| |
Map the ADMA2 descriptor table use BUS_DMA_COHERENT and add a missing
bus_dmamap_sync(9). Doesn't really fix anything, but adding the missing
sync makes the code more correct. Using BUS_DMA_COHERENT avoids some
cache flushes on architectures that implement it.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Code is slightly more convoluted to avoid using strncpy(9).
ok jsg@, millert@, deraadt@
|
| |
|
|
|
|
|
| |
transfer rates to and from the card. In practice the improvement will be
smaller, but I am seeing serious improvement in the read speeds.
|
|
|
|
| |
ok deraadt@, patrick@
|
|
|
|
| |
ok deraadt@, patrick@
|
|
|
|
|
|
|
| |
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 for it. In principle SD cards use high speed timing for frequencies
over 25MHz, but it is silly to run those with a clock between 25-26MHz.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
| |
value when initializing function 0, and correct a few related #defines.
ok deraadt@
|
|
|
|
| |
ok jsg@
|
|
|
|
|
|
|
|
| |
controller on Intel's Bay Trail SoC tends to be used in a way where a
separate gpio is used that signals the presence of a card in a slot. This
change allows us to support that mode.
ok stsp@
|
|
|
|
|
|
|
|
| |
local ones to ``nticks''.
(missed in previous)
ok stefan@, deraadt@
|
|
|
|
|
|
| |
them. Add symbolic constant for CISTPL_END.
ok jsg@
|
|
|
|
|
|
|
| |
SD host controller standard. Support the larger base clock and larger
clock divisors.
ok jsg@
|
|
|
|
|
|
|
|
|
|
|
|
| |
are not quite right. At least I can't find them in any of the MMC and
SD card documentation I can find on the interwebs. Instead there is a
single "low voltage bit" that indicates support for the 1.65-1.95V or
1.70-1.95V range depending on the document you're reading. Go with the
1.65-1.95V range as that is what Linux does.
Necessary (but not sufficient) to make the eMMC on the ASUS X205TA work.
ok jsg@ (who did the armv7 bits)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.
ok tedu@ deraadt@
|
|
|
|
| |
max@M00nBSD.net's code scanner; ok doug@ jca@
|
|
|
|
| |
ok deraadt@ tedu@
|
| |
|
|
|
|
|
|
| |
Based on a diff by Cedric Tessier, nezetic at gmail dot com, thanks!
Discussed with and ok jsg@
|
|
|
|
| |
ok mpi@ kspillner@
|
|
|
|
| |
after discussions with beck deraadt kettenis.
|
|
|
|
|
|
| |
bluetooth support doesn't work and isn't going anywhere. the current
design is a dead end, and should not be the basis for any future support.
general consensus says to whack it so as to not mislead the unwary.
|
|
|
|
|
| |
but at least lets the reader on X220 work pretty reliably, rather than about
1/4 of the time. ok stsp@
|
|
|
|
|
| |
Such as during DVACT_RESUME...
ok guenther kettenis
|
|
|
|
| |
ok stsp
|
|
|
|
|
|
|
|
| |
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op's in drivers
creating callback/threads themselves, but that has become too common,
indicating the need for a built-in mechanism.
ok dlg kettenis, tested by a sufficient amount of people
|
|
|
|
| |
ok matthew guenther mikeb
|
|
|
|
|
|
|
|
|
| |
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@
|