From owner-freebsd-arm@FreeBSD.ORG Thu May 24 20:27:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99255106566B for ; Thu, 24 May 2012 20:27:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 481078FC16 for ; Thu, 24 May 2012 20:27:07 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4OKNRwC069855 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 24 May 2012 14:23:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FBE93A7.7050502@gmail.com> Date: Thu, 24 May 2012 14:23:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FBE93A7.7050502@gmail.com> To: Ben Gray X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 24 May 2012 14:23:29 -0600 (MDT) Cc: freebsd-arm@freebsd.org Subject: Re: SDIO driver X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:27:07 -0000 On May 24, 2012, at 2:01 PM, Ben Gray wrote: > Hi all, >=20 > I've being doing some work on hacking SDIO support into the kernel. = My changes build on top of the current MMC/MMCBR module. Expanding the = diagram from Warner Losh's pdf = (http://www.bsdcan.org/2007/schedule/attachments/23-freebsd-sd-warner-losh= .pdf), my hacks have the following logic layout >=20 >=20 > +------------+ +------------+ > | ti_mmchs0 | | ti_mmchs1 | > +------------+ +------------+ > | | > | | > +--------+ +--------+ > | mmc0 | | mmc1 | > +--------+ +--------+ > | | > +------+-----+ | > | | | > +---------+ +---------+ +---------+ > | mmcsd0 | | mmcsd1 | | sdio0 | > +---------+ +---------+ +---------+ > | > | > +------+-------+------- .... -----+ > | | | > function#1 function#2 = function#7 > +----------+ +-----------+ = +----------+ > | wifi | | bluetooth | .... | = whatever | > +----------+ +-----------+ = +----------+ >=20 >=20 > So my sdio module sits at the same level as the current mmcsd module = and uses the same interface to talk to the mmc0 module (notably = MMCBUS_WAIT_FOR_REQUEST). The sdio part does the card setup and CIS = scanning, then enables any child functions and probes for a suitable = child driver. I think this is one layer too low in the tree. This is bus code, and = should be in the mmc bus. sdio drivers can then attach, and multiple = functions can attach multiple drivers more easily. > The problem with this approach is that currently a driver can target = only one logic function on the card - I don't know if any driver will = ever need to span more than one function. But perhaps a bigger problem = is that it doesn't support 'combo cards' (cards with both I/O and = standard SD memory). However supporting combo cards, I think, would = require a lot more changes to the current mmc/mmcsd drivers which I'm = reluctant to do. Yes. That's one of many problems, since SD I/O cards also need some = additional stuff in the enumeration, which may be tricky to reliably do = in the lower layers like you've done. In addition, there would need to = be some bus/bridge interfaces because some mmc/sd controllers can't do = SD I/O transactions. > Anyway I'm interested in whether anyone thinks this is useful in it's = current form? or whether the above limitations are too much of a = problem? If others are happy and would like it in the tree then perhaps = I can commit it to the armv6 branch for review? I'd be interested in taking a look. > Lastly the code is not quite complete as there are still corner cases = that need to be fixed, however in it's current form it works with a = basic wifi driver I've written for the Pandaboard (can load f/w, read = registers, etc). Which wifi card? Warner=