From owner-freebsd-hackers@FreeBSD.ORG  Sun Feb 16 11:11:55 2014
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 041224D4;
 Sun, 16 Feb 2014 11:11:55 +0000 (UTC)
Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2])
 by mx1.freebsd.org (Postfix) with ESMTP id B710C148F;
 Sun, 16 Feb 2014 11:11:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 6323E3F4AD
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default;
 t=1392549113; bh=1YEok5W3WRRe4z5jSbz55ecJDDiFetyEzUKLCgD+P4M=;
 h=Date:From:To:Cc:Subject;
 b=eRAL6XLE4J4EyND+WC4CFpuVhf/mcGYSvE0C/ZUMlzA7MqCdQ1InGBJl581JLeSHY
 r+fwhGYBaoyavMIV5Z093m52zImQ6WhEtZt4NWevCjkX8gPp93XDtFwqwlQfBfmY2S
 tfNm4Pluhq2fbGeRIV0hE+3WcksVqWG2nPCkXbZ4=
Date: Sun, 16 Feb 2014 12:11:53 +0100
From: Ilya Bakulin <ilya@bakulin.de>
To: Adrian Chadd <adrian.chadd@gmail.com>,
 Alexander Motin <mav@freebsd.org>, Warner Losh <imp@bsdimp.com>
Subject: MMC/SDIO stack under CAM
Message-ID: <20140216111153.GA74858@olymp.kibab.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J"
Content-Disposition: inline
Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2014 11:11:55 -0000


--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

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.

--
Ilya

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (FreeBSD)

iEYEARECAAYFAlMAnPcACgkQo9vlj1oadwhvqQCdHvVy3fWYl6m49MBpKpDfk2XG
i/UAn1LsZym1H2QokRa3V9KowxHqgqrK
=rC+Z
-----END PGP SIGNATURE-----

--VbJkn9YxBvnuCH5J--