From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 16 18:05:45 2014 Return-Path: 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 114B1B03 for ; Sun, 16 Feb 2014 18:05:45 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C72A211D8 for ; Sun, 16 Feb 2014 18:05:44 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id i4so16826583oah.11 for ; Sun, 16 Feb 2014 10:05:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QOZ2jb5M5CNdjVCDwj/oN5YST4Oq1B2qpZOi3TDSFHE=; b=SdFqTsUn79mk0yk8sOf5C1znUOFFUtNnV+51IxPs1Ve2Y5a90Jj3DbFBNyE6DxHchC 0h6/+xTllI+dx2wJVFYo6ucg5lpYq9C7Xj7Num6n/Lfxj3QKMIQL+cY0BYUIn009O/bH j4ihmFF9Qhw12aWaoQ5iVVam/ImOWswOVF73mpjoxXF5mMpp2tBpQyNss8Nt8RqRMZh+ Ov4zNxCP3ygUPzAc+XqsdUeREt9RcBe6ijS12xPk9bTqdQNPEum7IgWW0NQuhJbrpW1f iSL1QU4RCz3PknxLMWBg3BvSLAInDcYudjfQB8B1+s06OkvB+US6xc8CkoGDB1FgcFdR pIiA== X-Gm-Message-State: ALoCoQmFtyQsA2sTFV+aSxdYuGP51DbfLvYAvaWomth2DYebLPS7s6nKfVR5wLjzv+ilhjZdENHA X-Received: by 10.182.241.8 with SMTP id we8mr5116obc.62.1392573938012; Sun, 16 Feb 2014 10:05:38 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o6sm87669176oel.4.2014.02.16.10.05.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 10:05:36 -0800 (PST) Sender: Warner Losh Subject: Re: MMC/SDIO stack under CAM Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140216111153.GA74858@olymp.kibab.com> Date: Sun, 16 Feb 2014 11:05:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> References: <20140216111153.GA74858@olymp.kibab.com> To: Ilya Bakulin X-Mailer: Apple Mail (2.1085) Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 18:05:45 -0000 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=