Writing a driver for a card reader controller - how?
M. Warner Losh
imp at bsdimp.com
Sat Nov 26 06:39:21 GMT 2005
In message: <20051125105626.GA99656 at mygiea.ham01.thiemo.net>
Thiemo Nordenholz <listmember at thiemo.net> writes:
: > Do you have a copy of the MMC standard?
: Let's say, I have access to one.
I have access to the sanitized versions of the standard as well, but
not the full standard.
: > Does the MMC standard actually define a standard host interface?
: It seems to describe a set of registers, their sizes and possible content,
: but I have yet to find out how to send the commands to the card that are
: defined by the standard. It seems like this must be done by the controller.
There's two sets of registers that I've been able to find. One is the
set of hardware registers on the host which the host uses to interact
with the card. This is the critical one to discover, because without
it, we cannot hope to make things work with the card. Looks like
Linux has a few different mmc bridges that they support.
The second set is described in the sub-set of the standard I was able
to find on the mmc web site. These registers are standard, and I
anticipate that FreeBSD will have a mmc-bus layer that interacts with
these things. My initial take on the newbus hierarchy will look
winbondmmcbr timmcbr atmmcbr
| | |
mmcbus mmcbus mmcbus
| | |
mmcf mmcf mmcf
Where each bridge driver takes care of providing a standard inteface
to the mmcbus layer. That layer would provide the means to do
transfers and the like. mmcf would be the interface presented to the
user for mmc flash cards.
There's also new mmc I/O cards that have been defined. I don't know
if they are in use yet or not, but web searches for mmc + bluetooth
will show some results. I'd imagine that we'd have a mmcbt driver
that attaches to mmcbus if such devices ever become mainstream.
mmc slots can also support sd slots (well, most sd/mmc slots are
really sd slots, but since mmc is a subset of sd in many ways, support
for both is often paired). sd has some potentially probelmatical
intellectual property issues, but we should design a framework that
would allow a sdbus, mgatebus, etc to also attach to the above
More information about the freebsd-hackers