Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 May 2012 21:01:43 +0100
From:      Ben Gray <ben.r.gray@gmail.com>
To:        freebsd-arm@freebsd.org
Subject:   SDIO driver
Message-ID:  <4FBE93A7.7050502@gmail.com>

next in thread | raw e-mail | index | archive | help
Hi all,

    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


              +------------+       +------------+
              | ti_mmchs0  |       | ti_mmchs1  |
              +------------+       +------------+
                    |                     |
                    |                     |
               +--------+            +--------+
               |  mmc0  |            |  mmc1  |
               +--------+            +--------+
                    |                     |
             +------+-----+               |
             |            |               |
        +---------+  +---------+     +---------+
        |  mmcsd0 |  |  mmcsd1 |     |  sdio0  |
        +---------+  +---------+     +---------+
                                          |
                                          |
                                   +------+-------+------- .... -----+
                                   |              |                  |
                               function#1     function#2        function#7
                              +----------+   +-----------+      +----------+
                              |   wifi   |   | bluetooth | .... | whatever |
                              +----------+   +-----------+      +----------+


   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.

   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.

   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?

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

Cheers,
Ben.




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