| Age | Commit message (Collapse) | Author |
|---|
|
|
|
devices. This allows SDIO device drivers to read information from
the ACPI or FDT tables.
ok kettenis@
|
|
and thus only supported 4 functions instead of 8.
ok kettenis@
|
|
slow booting up, so give it a bit longer to enable the clock.
ok patrick@
|
|
sent in order. Otherwise it is possible that the key is set before
we send out the EAPOL packet, or that packets are sent out before
the key is set. Thus modify the SDIO backend to put both types into
the same internal TX queue, which will be sent asynchronously.
Discussed with bluhm@
|
|
|
|
another packet (even though nextlen is set to none) to issue more RX
interrupts.
|
|
instead of from a task. The sdmmc(4) interrupt handler is already
executed in process context and returning from the interrupt handler
without acknowledging the interrupts may lead to an interrupt storm.
ok patrick@
|
|
is only bumped if the high-speed mode is available.
ok kettenis@
|
|
local variable dangling, so calculate the lock address by hand at invocation
ok kettenis
|
|
mode, so switch from 1-bit to 4-bit bus width if the host controller
supports it.
ok kettenis@
|
|
ok kettenis@
|
|
sdmmc_io_rw_extended() function and loading the passed buffer
using the bus dma API akin to the SDMMC memory card code. The
2-byte and 4-byte accessors continue to use PIO.
ok kettenis@
|
|
to send/receive data. This basically means that we cannot use any
malloc(9)'d buffer. For this, use dma_alloc(9) to allocate a buf
that can fit a whole SDIO frame (unfortunately without headers).
Keep note that we need to round up the transfer sizes to block-
sized (for TX packets) or 4-byte alignment, since some DMA con-
trollers truncate the request size. If there's anything wrong,
the KASSERTs will catch it.
ok kettenis@
|
|
SDHC controllers get confused if the ADMA bit is set even though we
don't set the DMA enable flag. This can happen with the SDIO stack
which uses PIO for 4 byte read/writes but DMA for larger transfers
and thus switches from one mode to the other.
ok kettenis@
|
|
ok patrick@
|
|
ok patrick@
|
|
copied. This severely limits the speed over the bus. By using
block mode we can issue block-sized transfers, which bumps the
transfer size to at least 512 bytes. By using multi-block mode
we can copy up to 511 blocks per transfer.
ok kettenis@
|
|
this is only for memory card read/writes.
ok kettenis@
|
|
by florian@ when firmware isn't present initially.
|
|
and initialize bwfm(4) later in the case that the firmware was not
available on bootup and was only later installed.
ok stsp@
|
|
|
|
ok stsp@
|
|
firmware requires on SDIO-connected chips.
From ketttenis@
|
|
over the SDIO bus by accessing the correct addresses. This helped
me find the RX FIFO overflow issue and might help find more issues
where the chip's firmware complains about our wrongdoing.
|
|
plus hardware header, which tell us the length of the following data),
we can issue full packet reads. The software header contains a field
that informs us of the full length of the next frame that we can read,
so we can do that in a single sitting. This brings us down from three
SDIO read invocation to a single one per packet for a given RX stream.
|
|
of those is a sequence number based window mechanism. Essentially every
packet on the SDIO bus has a sequence number. The chip records which
sequence number we used last and when it sends us replies, it tells us
the maximum sequence number it accepts. This means we can calculate a
window of sequence numbers that we are allowed to use. With this I no
longer overflow the chip's RX fifo and can do stable network transfers.
|
|
the caller. Otherwise we skip restarting the ifq which means that if
we ever have a full queue and go oactive, there is no coming back. So
break out from the loop and call ifq restart if the queue is not full.
|
|
ids. So far we were only able to have one command in flight at a time
and race conditions could easily lead to unexpected behaviour, especia-
lly combined with a slow bus and timeouts. With this rework we send or
enqueue a control packet command and wait for replies to happen. Thus
we can have multiple control packets in flight and a reply with the
correct id will wake us up.
|
|
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@
|
|
suggested by coverity (via daniel@)
|
|
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@
|
|
frequency.
ok patrick@, visa@
|
|
memory regions.
|
|
SDIO function. This is necessary for some SDIO cards that need to be
talked with using smaller block lengths than the maximum supported by
the host controller.
ok kettenis@
|
|
interface for "reading memory" akin to the bus_space(9) API. The
already existing multi interface is used for "reading FIFOs". The
technical difference is that one always reads from the same address
(FIFO) while the other increments the address while reading (memory).
ok kettenis@
|
|
alignment can be variable, it's better to move taking care of alignment
into the BCDC receive code.
|
|
receive. Did that everywhere else but missed it here.
|
|
|
|
converts the logic of the upper layers (sending control messages,
sending data messages, receiving event or data messages) into the
corresponding work that has to be done on the lowest layer. SDIO
is not the fastest bus for exchanging network packets, but maybe
there is room for tuning. Actual TX/RX is being done in a worker
task that serializes access to the hardware. This is good enough
to attach to WiFi networks and do network transfers. Developed
and tested on a Cubox-i.
|
|
can be called and reused in different places.
|
|
into one header specific to the SDIO attachment driver. Also
add more register and protocol definitions to it.
|
|
to account for any relevant hardware constraints.
ok stsp@
|
|
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
|
