From owner-freebsd-embedded@FreeBSD.ORG Thu Oct 10 21:04:04 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8BFEC54; Thu, 10 Oct 2013 21:04:04 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 637AB2DD0; Thu, 10 Oct 2013 21:04:02 +0000 (UTC) X-DKIM: OpenDKIM Filter v2.5.2 olymp.kibab.com 964183F461 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1381439033; bh=NNOJeBpSBw2HFC5cdZ5uHihs56/1nILPwHCUqKof05k=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=mJHqy9cfH4dbtPzkix6UtL4yAtBD9zHD9bo6hJRkZz0PW4X+sIh3IbWqy+klxhpKg AXVQG0PJ2uAlMHflclS3e7ciEnPRkDly0CEeFfpSBVGGVlnBWNRis0iB6TrY96T9PA hJoUaZLuX5mD/MDqKKP0sGYarJDuGVmEszzrs72w= Message-ID: <52571635.6080708@bakulin.de> Date: Thu, 10 Oct 2013 23:03:49 +0200 From: Ilya Bakulin MIME-Version: 1.0 To: Alexander Motin Subject: Re: SDIO for FreeBSD: CAM integration References: <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> <5254892B.3050507@bakulin.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0" Cc: freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:04:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 09.10.13 00:57, Alexander Motin wrote: > CAM has mechanism of asynchronous notifications, that is quite alike to= > interupts. That's good to know! So, after reading a bit more about CAM I have some kind of design proposa= l. In CAM world, we have peripheral modules (da, cd, pt, ses) and software interface modules, SIMs (USB, ATA, ATAPI, Firewire). The current implementation of MMC stack has three layers: 1. mmcsd(4) driver, later also SDIO device drivers {mv_sdiowl, ar6xxx,...= } 2. mmc(4) stack 3. SD controller {sdhci(4), mvsdio, ti_mmc,...} As far as I understand, it makes sense to convert the mmcsd driver to "peripheral module" and mmc stack will be then SIM. The relation of mmc stack and SD controller is then... well, essentially, those are just two parts of the SIM. They will still find each other using the NewBus. We can then drop that msleep() in MMC stack waiting for the SD controller to signal the completion of our request and just return, setting CAM_REQ_INPROG status in the CCB. When the controller receives an interrupt, its ISR calls into the MMC stack directly, the MMC stack then calls xpt_done() and the CCB is returned to the peripheral driver. In the SDIO case, when there is no active CCB, the MMC stack issues an asynchronous notification. So, based on this proposal, the first thing I will do is adding a CAM layer between mmcsd(4) and mmc(4) so this will still work as before :-) Does this all make sense to you? --=20 Regards, Ilya Bakulin --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJXFjkACgkQo9vlj1oadwjjgACgxdiGH32Smr+kLf3ltOWPPHH8 UFcAmgPeRJMFmMfNEYjS0cPac+dztR9s =ZW2m -----END PGP SIGNATURE----- --dGuvnXLtI7SRnJgV7ajN4vCbl5XAaM2n0--