Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Oct 2013 23:03:49 +0200
From:      Ilya Bakulin <ilya@bakulin.de>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        freebsd-embedded@freebsd.org
Subject:   Re: SDIO for FreeBSD: CAM integration
Message-ID:  <52571635.6080708@bakulin.de>
In-Reply-To: <CAO4K=PUp3tNg1vTTEjKj7fZ0pLeadRV6%2Bf=FWO8ko5xybZDcoA@mail.gmail.com>
References:  <5251A9D3.1080803@bakulin.de> <5251C911.6020003@FreeBSD.org> <CAJ-Vmon0xr597We=sF5Uhja2qb=viuiqCbQXZgUvp7VX-FsPfA@mail.gmail.com> <4FB11076-DD88-43F2-A449-E41D2088A4DD@bsdimp.com> <5254892B.3050507@bakulin.de> <CAO4K=PUp3tNg1vTTEjKj7fZ0pLeadRV6%2Bf=FWO8ko5xybZDcoA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52571635.6080708>