kibab / freebsd Goto Github PK

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.

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

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.

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.

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)."

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).

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.

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.

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

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.

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.