Date: Sun, 16 Feb 2014 11:05:35 -0700 From: Warner Losh <imp@bsdimp.com> To: Ilya Bakulin <ilya@bakulin.de> Cc: Adrian Chadd <adrian.chadd@gmail.com>, freebsd-hackers@freebsd.org, Alexander Motin <mav@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: MMC/SDIO stack under CAM Message-ID: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> In-Reply-To: <20140216111153.GA74858@olymp.kibab.com> References: <20140216111153.GA74858@olymp.kibab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > Below is the structure for USB sticks: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer sys/cam/scsi/*| > +------------------------+ > | > CCB > | > +------------------+ > |umass (HBA =3D=3D SIM)| > +------------------+ > | > usbd_* > | > +--------------------------+ > |USB stack (and controller)| > +--------------------------+ >=20 > 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: >=20 > +-----------------------+ > |Kernel (disk interface)| > +-----------------------+ > | > BIO > | > +-------------------+ > |da (storage driver)| > +-------------------+ > | > CCB > | > +------------------------+ > |CAM Layer (sys/cam/mmc/*| > +------------------------+ > | > CCB > | > +-------------------+ > |mmc_cam (HBA =3D=3D SIM| > +-------------------+ > | > SD/MMC protocol (struct mmc_request) > | > +-------------------------------------------+ > | MMC ctrlr driver (sdhci_ti, ..., mmcnull) | > +-------------------------------------------+ > | > | > +------------------+ > | MMC/SD/SDIO Card | > +------------------+ >=20 > (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). >=20 > 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. >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C2CF572-360D-4CA0-81C7-18A5C455AED5>