Date: Mon, 24 Feb 2014 15:26:42 +0100 From: Ilya Bakulin <ilya@bakulin.de> To: Warner Losh <imp@bsdimp.com> 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: <20140224142642.GA32538@olymp.kibab.com> In-Reply-To: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2014 at 11:05:35AM -0700, Warner Losh wrote: > 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 hi= nd sight, it would have saved a lot of time). I assume that by "mmcsim" you mean not MMC SIM for CAM, but MMC SIMulator := -) Yeah so essentially it should be able to return some "fake" data to the upper layer, maybe based on configuration (ie 1 GB SD, 16 GB SDHC, .= =2E.). > > 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. >=20 > Generally, I like this idea... I'd be very interested in some of the spe= cifics 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 S= DIO cards and how they's interact with CAM in this scenario... >=20 > The notion of moving MMC/SD into the CAM stack has been around since I st= arted working on MMC. At the time, CAM was too SCSI centric to do it, but A= lexander Motin's work has generally improved that situation, so it may be p= ossible now to do it and shake out the few dark corners of CAM where this i= sn't the case. I also think it should help performance a lot since we're cu= rrently 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. >=20 > Warner After talking with Alexander about CAM, here is the updated proposal: * All card communication logic should be placed in MMC XPT layer, with the = new CCB type that describes MMC request + some data needed by the system. So almost everything from sys/dev/mmc/mmc.c goes there. * da(4) is a driver for SCSI disks. It makes more sense to adapt mmcsd(4) t= o use CAM. So mmcsd(4) will create CCBs and pass them to CAM layer, getting async no= tifications via standard CAM callback mechanism. * It is possible to write drivers for SDIO devices exactly like adopted mmc= sd(4). Every such driver would be then built as CAM peripheral driver, which mea= ns it will be able to send/receive CCBs. To do that, every driver has to call PERIPHDRIVER_DECLARE() macro, subscr= ibing to CAM "new device found" events. The ongoing work for MMC CAM is here: https://github.com/kibab/freebsd/compare/master...mmccam Not so much stuff here yet. PS: In theory, ssince there is already an existing interface for passing CA= M CCBs between userland and kernel, it WOULD be posssible to create device drivers entirely in userland... Like= microkernel OSes do. But our network stack doesn'have such feature I guess... -- Ilya --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlMLVqAACgkQo9vlj1oadwjVWACg7ZgrzQ4f31Si3XN5p9Y3LLeC N84AoKTada+XSlMYa8t6JVfZVz/zJNx2 =XWE5 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140224142642.GA32538>