Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: 886927bbcb
Fetching contributors…

Cannot retrieve contributors at this time

190 lines (160 sloc) 6.679 kb
The Char SDIO Device Driver is an interface which exposes an SDIO
card/function from kernel space as a char device in user space.
The driver doesn't interact with any HW directly. It relies on SDIO
card/function interface provided as a part of Linux kernel.
Hardware description
Each SDIO device/card contains an SDIO client HW block.
The host interacts with the device by sending byte sequences called
command (CMD). Some commands can be followed by data blocks. The
device sends back a byte sequence called response (R) and a data
block if required. CMD3, CMD5 and CMD7 are used to initialize the
device. CMD52 and CMD53 are used to access the device. Command
format and properties are defined by SDIO Specification document
published by SD Association:
CMD52 and CMD53 can access up to 8 address spaces called Functions.
Function 0 contains system information predefined by SD/SDIO
standard and Functions 1-7 are defined by the SDIO device
An SDIO device/card can send an interrupt to SDIO host. This
interrupt is intercepted and handled by SDIO host.
Software description
Linux provides a framework for handling SDIO devices. It implements
kind of plug-and-play model in which the Linux SDIO Host Driver is
responsible for initializing an SDIO device upon insertion. It also
reads device/card identification information and enumerates functions
provided by the device and then looks up in the list of
preregistered user SDIO drivers for a suitable one.
During its lifecycle the user SDIO driver interacts with the Linux
SDIO Host Driver in order to send/receive information to/from SDIO
device/card. The user SDIO driver doesn't work with CMD52/CMD53
directly. Instead it uses an abstraction provided by the Linux SDIO
Host Driver.
The Linux SDIO Host Driver is also in charge of handling SDIO
interrupts. User SDIO driver can register its own callback in SDIO
Host Driver and get a notification about interrupt event.
The Char SDIO Device Driver follows the design guidelines mentioned
above. It provides the following functionality:
- Register itself in the user SDIO drivers list;
- Handle Probe event upon insertion of supported card/device;
- Creates and maintains a char device driver for each SDIO Function
found in the card/device;
- Translates read/write/ioctl calls to appropriate SDIO call
In order to handle general SDIO configuration functionality and
Function 0 the Char SDIO Device Driver provides additional
simplified char device driver.
The Manufacturer and Device IDs of handled SDIO device should be
provided as parameters for kernel module or as configuration
parameters in case of statically linked driver.
The main goal of the Char SDIO Device Driver is to expose an SDIO
card/device from kernel space to user space as a char device driver.
The driver should be generic and simple as far as possible.
The biggest design tradeoff is maintaining a balance between the
system call overhead required to initiate an SDIO transaction from
user space and overall SDIO communication performance. But luckily,
because of nature of SDIO protocol, this overhead is negligible
comparing to time required to execute SDIO transaction itself. So,
each CMD52 (read or write) consists from single ioctl system call.
And each CMD53 invokes single ioctl system call followed by read or
write system call.
The Char SDIO Device Driver registers its own class of the devices
called 'csdio'. This class will serve as a common roof for all SDIO
devices served by different instances of the Char SDIO Device Driver.
Additional benefit from maintaining its own class is the driver
ability to overwrite default permissions of the dev nodes created by
the driver.
Power Management
The driver does not anticipate any issues related to multi-core
since it is expected to run on one core only.
The Char SDIO Device Driver has two char device interfaces:
- Control Interface;
- Function Interface.
Char SDIO Device Driver Control Interface consists of:
- open() - device node is /dev/csdio0;
- close()
- ioctl() - the following options are available:
Char SDIO Device Driver Function Interface consists of:
- open() - device node is /dev/csdiofX, where X is Function Id;
- close()
- read() - send CMD53 read;
- write() - send CMD53 write;
- ioctl() - the following options are available:
- CSDIO_IOC_SET_OP_CODE - 0 fixed adrress, 1 autoincrement.
- CSDIO_IOC_SET_BLOCK_MODE - 0 byte mode, 1 block mode;
- CSDIO_IOC_CMD52 - execute CMD52, receives the
following structure as a parameter:
struct csdio_cmd52_ctrl_t {
uint32_t m_write; // 0 - read, 1 -write
uint32_t m_address;
uint32_t m_data; // data to write or read data
uint32_t m_ret; // command execution status
}__attribute__ ((packed));
- CSDIO_IOC_CMD53 - setup CMD53 data transfer, receives the
following structure as a parameter:
struct csdio_cmd53_ctrl_t {
uint32_t m_block_mode;
uint32_t m_op_code;
uint32_t m_address;
}__attribute__ ((packed));
Additionally, user space application can use fcntl system call with
parameters F_SETOWN and F_SETFL in order to set an asynchronous
callback for SDIO interrupt.
Driver parameters
If the driver is compiled as a kernel module, the following
parameters can be used in order to provide Manufacturer and Device IDs
upon module download:
- csdio_vendor_id;
- csdio_device_id.
If the driver is intended to work with specific SDIO host the
host_name parameter should be added followed by the name of the MMC
host platform device.
Config options
These are the kernel configuration options:
The Char SDIO Device Driver depends on Linux SDIO Host Driver.
User space utilities
Known issues
To do
Provide mechanism to support a number of SDIO devices simultaneously
connected to different SDIO hosts.
Jump to Line
Something went wrong with that request. Please try again.