MMC/SDIO stack under CAM

[Warner Losh]

On Feb 16, 2014, at 4:11 AM, Ilya Bakulin wrote:

> Hi list,
> so I still want to move SDIO stack integration forward.
> As was already discussed, the best thing to do would be to
> have MMC stack under CAM.
> I have tried to understand how the CAM works for the existing drivers.
> 
> Below is the structure for USB sticks:
> 
> +-----------------------+
> |Kernel (disk interface)|
> +-----------------------+
> 	 |
> 	BIO
> 	 |
> +-------------------+
> |da (storage driver)|
> +-------------------+
> 	 |
> 	CCB
> 	 |
> +------------------------+
> |CAM Layer sys/cam/scsi/*|
> +------------------------+
> 	 |
> 	CCB
> 	 |
> +------------------+
> |umass (HBA == SIM)|
> +------------------+
> 	 |
> 	usbd_*
> 	 |
> +--------------------------+
> |USB stack (and controller)|
> +--------------------------+
> 
> So da(4) doesn't know anything about USB.
> At this point I thought, that in this case da(4)
> will happily communicate with MMC/SD cards, if we provide
> a SIM for MMC! So the structure for MMC would be like this:
> 
> +-----------------------+
> |Kernel (disk interface)|
> +-----------------------+
> 	 |
> 	BIO
> 	 |
> +-------------------+
> |da (storage driver)|
> +-------------------+
> 	 |
> 	CCB
> 	 |
> +------------------------+
> |CAM Layer (sys/cam/mmc/*|
> +------------------------+
> 	 |
> 	CCB
> 	 |
> +-------------------+
> |mmc_cam (HBA == SIM|
> +-------------------+
> 	 |
> SD/MMC protocol (struct mmc_request)
> 	 |
> +-------------------------------------------+
> | MMC ctrlr driver (sdhci_ti, ..., mmcnull) |
> +-------------------------------------------+
> 	 |
> 	 |
> +------------------+
> | MMC/SD/SDIO Card |
> +------------------+
> 
> (the mmcnull driver is the pseudo-driver that I'm writing
> to make it possible to develop and test the whole thing
> on the VM).

that's cool! I'd thought of writing a mmcsim that I could use to develop the stack on x86, but time pressures of my job precluded that (though in hind sight, it would have saved a lot of time).

> So MMC SIM and MMC controller driver would exchange mmc_requests,
> as it was before, with the exception that command completion will be
> reported differently (to utilize async callbacks system of CAM).
> 
> For SDIO card, the situation will be different. Essentially,
> we should allow a device driver to send arbitrary messages to the card.
> So the device driver will attach directly to the scbus.
> 
> Please let me know your thoughts about it.
> I really want SDIO make its way into the kernel, because there
> is an increasing number of ARM boards on the market that have integrated
> SDIO WLAN on them and we cannot support them fully.

Generally, I like this idea...  I'd be very interested in some of the specifics to make the direct attachment work with SDIO. That's the one area I either don't think I understand your proposal well enough, or I do and I'm concerned about it. :) So maybe write a bit more about the details of the SDIO cards and how they's interact with CAM in this scenario...

The notion of moving MMC/SD into the CAM stack has been around since I started working on MMC. At the time, CAM was too SCSI centric to do it, but Alexander Motin's work has generally improved that situation, so it may be possible now to do it and shake out the few dark corners of CAM where this isn't the case. I also think it should help performance a lot since we're currently single threaded to the card (but that's also the nature of the bus), which introduces some round-trip latencies between too many threads that CAM may help us avoid.

Warner