summaryrefslogtreecommitdiffstats
path: root/sys/dev/sdmmc (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Don't detach non-removable devices during resume on "sdhc* at acpi?".stsp2019-04-024-5/+11
| | | | | | Makes hibernate work with rootfs on built-in emmc storage. Tested on King Jim Portabook. ok deraadt@ kettenis@
* Consistently use m_freem(9). This fixes possible leaks in a fewpatrick2019-02-071-2/+2
| | | | error cases.
* Turns out we do need to handle control messages that exceed MLEN, sokettenis2019-02-041-6/+15
| | | | | | | allocate a cluster if the message is larger than that. Fixes a panic on shutdown on my Asus X205TA. ok patrick@, stsp@
* Allow passing the maximum size of a segment that a SD/MMC hostpatrick2018-12-293-4/+8
| | | | | | controller can handle for DMA tranfers, since not all support 64k. ok kettenis@
* Avoid using m_trailingspace(9) on an mbuf allocated with MGET(9) as it relieskettenis2018-12-221-2/+4
| | | | | | | | | | | | on header fields that aren't initialized, which may trigger an assertion. Check whether the control message doesn't exceed MLEN instead and turn the check into a KASSERT as the driver should not generate control messages that are larger. with help form claudio@ (who points out that the driver should not use MT_CONTROL here). ok patrick@
* M_LEADINGSPACE() and M_TRAILINGSPACE() are just wrappers forclaudio2018-11-091-2/+2
| | | | | | m_leadingspace() and m_trailingspace(). Convert all callers to call directly the functions and remove the defines. OK krw@, mpi@
* Implement 64-bit DMA support in sdhc(4).patrick2018-09-062-10/+39
| | | | | tested in snaps ok kettenis@
* Implement out-of-band interrupt support in the bwfm(4) SDIO backend.patrick2018-08-091-1/+45
|
* Allow passing per-function cookies through the SD/MMC bus to SDIOpatrick2018-08-094-4/+11
| | | | | | | devices. This allows SDIO device drivers to read information from the ACPI or FDT tables. ok kettenis@
* Correct the bitmask that returns the function count. We missed a bitpatrick2018-08-091-2/+2
| | | | | | and thus only supported 4 functions instead of 8. ok kettenis@
* Add support fotr the BCM4335/4339 SDIO chip to bwfm(4). This one is a bitkettenis2018-07-241-8/+16
| | | | | | slow booting up, so give it a bit longer to enable the clock. ok patrick@
* TX packets, which can be either Ethernet or control packets, must bepatrick2018-07-171-93/+108
| | | | | | | | | 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@
* Add support for the BCM43455 SDIO chip to bwfm(4).patrick2018-07-161-1/+6
|
* In certain modes SDIO-connected bwfm(4) chips might expect us to readpatrick2018-07-161-3/+3
| | | | | another packet (even though nextlen is set to none) to issue more RX interrupts.
* Run the code to handle interrupts directly from the interrupt handlerkettenis2018-06-181-3/+2
| | | | | | | | 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@
* Add curly braces to the if-condition to make sure the bus widthpatrick2018-06-171-3/+3
| | | | | | is only bumped if the high-speed mode is available. ok kettenis@
* in non-DIAGNOSTIC kernels, rw_assert_wrlock becomes a nop which leaves thederaadt2018-06-041-5/+3
| | | | | local variable dangling, so calculate the lock address by hand at invocation ok kettenis
* 4-bit bus width is mandatory for SDIO cards that support High Speedpatrick2018-06-043-7/+28
| | | | | | | mode, so switch from 1-bit to 4-bit bus width if the host controller supports it. ok kettenis@
* Switch to SDIO High Speed mode if the host controller supports it.patrick2018-06-042-5/+37
| | | | ok kettenis@
* Implement SDIO DMA support. This is achieved by wrapping thepatrick2018-05-301-11/+53
| | | | | | | | 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@
* For the upcoming SDIO DMA support we need to use DMA-able bufferpatrick2018-05-301-25/+64
| | | | | | | | | | | | | 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@
* Clear the DMA select bits in case we use PIO instead of DMA. Somepatrick2018-05-301-2/+3
| | | | | | | | | 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@
* BCM43430 SDIO works if we load the appropriate firmware.kettenis2018-05-271-1/+10
| | | | ok patrick@
* BCM4356 SDIO works if we load the appropriate firmware.kettenis2018-05-261-1/+5
| | | | ok patrick@
* So far the SDIO stack issued one transfer for every 64 byte to bepatrick2018-05-252-40/+66
| | | | | | | | | 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@
* For SDIO multi-blocks we must not use the AUTO CMD12 feature,patrick2018-05-251-3/+4
| | | | | | this is only for memory card read/writes. ok kettenis@
* Release rwlock on bwfm(4) SDIO initialization error. Fixes hang foundpatrick2018-05-241-8/+12
| | | | by florian@ when firmware isn't present initially.
* Implement a separate initialization stage so that we can still usepatrick2018-05-231-19/+24
| | | | | | | and initialize bwfm(4) later in the case that the firmware was not available on bootup and was only later installed. ok stsp@
* Extend list of supported bwfm(4) SDIO chips.patrick2018-05-231-4/+24
|
* Make the way we print "not configured" lines for SDIO devices a bit nicer.kettenis2018-05-211-7/+6
| | | | ok stsp@
* Consistently suffix the pre-processed NVRAM binary that the bwfm(4)'spatrick2018-05-211-4/+4
| | | | | | firmware requires on SDIO-connected chips. From ketttenis@
* Akin to the PCI attachment driver we can extract the chip's dmesg(8)patrick2018-05-192-2/+117
| | | | | | 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.
* After reading the first frame, which we can do in two reads (softwarepatrick2018-05-181-34/+61
| | | | | | | | 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.
* The Broadcom FullMAC firmware has a few ways of doing flow control. Onepatrick2018-05-171-2/+22
| | | | | | | | | 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.
* After having finished transmitting the last mbuf, don't just return topatrick2018-05-161-3/+4
| | | | | | 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.
* Implement a BCDC control packet mechanism based on the command requestpatrick2018-05-161-79/+25
| | | | | | | | | 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.
* Bump the clock frequency to a higher level that every card (per spec)patrick2018-05-011-1/+7
| | | | | | | 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@
* Add some sensible error checking in the hibernate io path, helpfullyjmatthew2018-03-301-3/+8
| | | | suggested by coverity (via daniel@)
* Add hibernate IO path for sdmmc(4). This requires some help from thejmatthew2018-03-207-10/+221
| | | | | | | | 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@
* Make it possible for the sdhc(4) attachment glue to specify the base clockkettenis2018-03-193-5/+13
| | | | | | frequency. ok patrick@, visa@
* Use the new APIs for setting block lengths and reading from/writing topatrick2018-02-111-6/+6
| | | | memory regions.
* Add sdmmc_io_set_blocklen() which allows to set the block length of anpatrick2018-02-114-7/+33
| | | | | | | | 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@
* Add sdmmc_io_read_region_1() and sdmmc_io_write_region_1() as anpatrick2018-02-112-2/+50
| | | | | | | | | 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@
* Since the BCDC header has a variable data offset, so the ethernet packetpatrick2018-02-111-2/+1
| | | | | alignment can be variable, it's better to move taking care of alignment into the BCDC receive code.
* Update the packet header length as well as the mbuf length onpatrick2018-02-111-2/+2
| | | | receive. Did that everywhere else but missed it here.
* fix build with SDHC_DEBUG defined, no binary change otherwisejmatthew2018-02-101-2/+2
|
* Implement the bwfm(4) SDIO bus logic. This is the bus layer thatpatrick2018-02-091-35/+859
| | | | | | | | | | | 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.
* Outsource setting the backplane window into a specific function so itpatrick2018-02-071-19/+19
| | | | can be called and reused in different places.
* Move SDIO bus and protocol definitions from the shared headerpatrick2018-02-072-1/+180
| | | | | into one header specific to the SDIO attachment driver. Also add more register and protocol definitions to it.
* Allow SD/MMC controller drivers to allocate their own DMA mapping structurekettenis2017-12-242-3/+5
| | | | | | to account for any relevant hardware constraints. ok stsp@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.