kibab / freebsd Goto Github PK

Sleeps are, strictly speaking, not allowed when doing probing. Migrate to something different, add more states to the probing state machine.

See https://reviews.freebsd.org/D12762, comment from Marius:

Side-note: Prior to UHS-II, the maximum transfer size for SDHCI is limited by the 16-bit block count register (that maximum may even shrink further depending on the re-tuning mode a particular SDHCI controller implements, though). So for !MMCCAM, shdci(4) correctly hardcodes 65535 for MMCBR_IVAR_MAX_DATA in the !re-tuning case. However, in case of MMCCAM, shdci(4) currently incorrectly sets cpi->maxio to MAXPHYS for XPT_PATH_INQ.

We need to counts statistics the same way it is done for ATA and SCSI transactions already. see cam_periph_runccb code.

This is required to reach feature parity with the old stack.

Currently it's not possible to request a block transfer using CMD53 if the resulting data size exceeds 512 bytes, because the code in sdhci.c uses <= 512 block size.

marius@ in https://reviews.freebsd.org/D12762#inline-79807:
Handling of suspend/resume in sdda(4) but also already starting in sdhci(4) in the MMCCAM case.

"You can send suspend/resume events to e. g. sdhci(4) instances via devctl(8), which should even work on ARM (but doing so with the system booted from an SD card probably isn't a good idea for starters)."

Provide a way for the driver developers to probe / attach to the SDIO devices. Maybe create an sdio(4) bus that provides probe and identify methods.
This might be more robust than to rely on CAM-provided bus/target/lun notation.

https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
https://people.freebsd.org/~imp/asiabsdcon2015/iosched-slides.pdf

https://github.com/freebsd/freebsd/blob/master/sys/cam/cam_iosched.h

UHS-I requires changes to initialization path to add voltage switches.
Supporting UHS will speed up I/O operations. Currently this is mostly useful for MMC/SD cards, don't know about SDIO.

Provide a way for the userland application to subscribe for notifications about card-generated interrupts. This is necessary for prototyping the device drivers in userspace.
Note: current pass(4) implementation already has something similar with CAMIOQUEUE / CAMIOGET ioctls, although they still assume that there is a request that should be queued from the userland in the kernel. Userland uses select / kqueue on /dev/passN FD for subscribing to request completion notification. Card-generated interrupts can use the same notification mechanism.

From marius@ comments in https://reviews.freebsd.org/D12762:
Handling of the timeout provided in mmc_switch_fill_mmcio(). Partly this needs to happen in sdhci(4), i. e. SDHCI_TIMEOUT_CONTROL needs to be set accordingly, but a counterpart to mmc_switch() of mmc_subr.c should live in CAM.

marius@ in https://reviews.freebsd.org/D12762:

Usage of cpi.maxio for disk->d_maxsize with the former set to an incorrect value by sdhci(4) (which obviously is an sdhci(4) bug, though).

Should not be a hard task with the high RoI ;-) because then it will be possible to test the new stack on actual PCs and laptops.