usr_blk_dev.c

包含MMC协议,驱动源码. 在LINUX操作系统下通过.

/*
 * Copyright 2005 Motorola, Inc. All Rights Reserved.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  
 * 02111-1307, USA
 *
 */
/*!
 * @file usr_blk_dev.c
 *
 * @ingroup usr_blk_dev
 *
 * @brief This is the main file for the user block driver.
 *
 * <B>Overview:</B><BR>
 *    The user block driver is a removable media block driver intended to allow
 * for user space drivers for the media.
 *
 *    This driver operates by creating an entry on /proc and using the entry
 * to communicate commands to user space.  See ::USR_BLK_DEV_CMD_ID_T for a list
 * of these commands.  Commands are sent from a kernel thread through /proc
 * to user space.  Once the user space process has completed the command it
 * responds with a write to the proc entry.  Only one command can be processed
 * at a time by a user space process and a kernel thread.  A thread is used
 * for the commands in order to keep the request queue from blocking which is
 * not allowed.
 *
 *    At this time a single thread is used for all devices attached.  This
 * is not intended to be the final design, but was done to speed up development.
 * This will be acceptable for systems which implement only one device.  If
 * more than one device is to be supported, then multiple threads should be
 * used, one per /proc entry.  This will speed up throughput, since one part
 * will not block the others.
 *
 * There are two different levels of command processing within this driver.
 * Commands from interrupts, the request queue and general file operations
 * (open, revalidate, check_media) are placed in the command structure
 * (usr_blk_dev_cmd_s) within the information structure (::USR_BLK_DEV_INFO_T)
 * for the device.  These commands are then processed by the kernel thread
 * (usr_blk_dev_thread()) and sent to user space.  Once they are processed by
 * user space, the kernel thread copies any return data and informs the source
 * of the command that it has been completed.
 *
 *   Part detection is done via a switch in the socket which is connected to
 * GPIO on the part.  An interrupt is generated on both the rising edge and the
 * falling edge of the signal.  Once an interrupt is detected a timer is used
 * do debounce the signal.  After the signal has achieved a steady state the
 * interrupt is re-enabled and the timer stopped.
 *
 * <B>Devices Created:</B><BR>
 *    -# /proc/usr_blk_dev0: The read/write interface to the user space driver
 *       for device 0.
 *    -# /proc/usr_blk_devn: The read/write interface to the user space driver
 *       for device n.
 * <B>Devices Used:</B><BR>
 *    -# /dev/mmca0: The root for the first detected card in the first slot.
 *    -# /dev/mmca\<n\>: The partitions of the detected card (up to 8 partitions
 *       are supported).
 *    -# /dev/mmcb0: The root for the card in the second slot if detected.
 *       Additional cards continue to increment the letter (c, d, e, ...).
 *    -# /dev/mmcb\<n\>: The partitions of the card in the second slot.
 *       Additional cards continue to increment the letter (c, d, e, ...).
 *
 * <B>Command Lifecycle:</B><BR>
 *    When a command is sent to the user block thread it transitions through
 * the states described in ::USR_BLK_DEV_CMD_STATE_T.  As they enter a new
 * state they may wait on a wait queue or wake up another queue as they
 * complete.  It is necessary for commands to cycle through the states or
 * they can hold up all subsequent commands.
 *
 *    The following describes the states and the wait queues used within them.
 * The state for the commands are stored in
 * usr_blk_dev_info[dev_num].cmd[cmd_src].state
 *
 * <B>#USR_BLK_DEV_CMD_STATE_NONE:</B><BR>
 *   This state can be considered the idle state of the driver.  This value sits
 * in the state variable when the no command is active.  A transition to the
 * ::USR_BLK_DEV_CMD_STATE_NEW state starts a command executing in the user block
 * thread.<BR>
 *
 * <B>#USR_BLK_DEV_CMD_STATE_NEW:</B><BR>
 *   This is the state a requester must put in the state value in order to start
 * a command executing.  In the case of commands which come from locations which
 * can block the wait queue usr_blk_dev_info[dev_num].cmd[cmd_src].wait_for_completion
 * must be used before the new command can be added.
 *
 * <B>#USR_BLK_DEV_CMD_STATE_THREAD:</B><BR>
 *   This value is placed in the state control variable as soon as the user block
 * thread detects the command is new.  It does not wait on any queues.
 *
 * <B>#USR_BLK_DEV_CMD_STATE_USR_READ</B><BR>
 *   When a command is in this state it has woken up the
 * usr_blk_dev_info[dev_num].wait_for_usr_read queue which controls when user
 * reads of the /proc entry happen.
 *
 * <B>#USR_BLK_DEV_CMD_STATE_USR_WAIT:</B><BR>
 *   This state is transitioned to as soon as the user process reads the command
 * from the /proc entry.  The command will remain in this state until the
 * response is written to the /proc entry from the user driver.  Commands in
 * this state (as well as the ::USR_BLK_DEV_CMD_STATE_USR_READ) are waiting on
 * the usr_blk_dev_info[dev_num].wait_for_usr_write queue.
 *
 * <B>#USR_BLK_DEV_CMD_STATE_USR_DONE:</B><BR>
 *   This state is entered as soon as the usr_blk_dev_info[dev_num].wait_for_usr_write
 * queue is awakened.  At this point the user block thread continues by processing
 * any necessary data.  If the data was from the request queue
 * (::USR_BLK_DEV_CMD_SRC_REQ) or an interrupt (::USR_BLK_DEV_CMD_SRC_IRQ) the command
 * is transitioned to ::USR_BLK_DEV_CMD_STATE_NONE since no more processing is
 * necessary. If it is not from one of these sources it will wake up the
 * usr_blk_dev_info[dev_num].cmd[cmd_src].wait_for_thread queue to allow the
 * requester to process the data.
 *
 * <B>#USR_BLK_DEV_CMD_STATE_THREAD_DONE:</B><BR>
 *   Once the user block thread is done executing a command the
 * usr_blk_dev_info[dev_num].cmd[cmd_src].wait_for_thread will be awakened and the
 * requester of the command will transition to this state.  Within this state
 * the requester will act upon the date returned and set the state back to
 * #USR_BLK_DEV_CMD_STATE_NONE.
 *
 * For more data on the individual commands see the ::USR_BLK_DEV_CMD_ID_T.
 */
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>

#include <stdbool.h>
#include <asm/arch/hardware.h>
#include <linux/blk.h>
#include <linux/blkdev.h>
#include <linux/blkpg.h>
#include <linux/fs.h>
#include <linux/genhd.h>
#include <linux/hdreg.h>
#include <linux/init.h>
#include <asm/irq.h>
#include <linux/proc_fs.h>
#include <linux/sched.h>
#include <linux/poll.h>
#include <linux/timer.h>
#include <asm/uaccess.h>
#include <linux/wait.h>

#include <linux/usr_blk_dev.h>

/******************************************************************************
* Local constants and macros
******************************************************************************/

/*!
 * @brief The number of successive times the sample of the device attach signal must
 * match before the device state is changed.
 */
#define USR_BLK_DEV_DEBOUNCE_CNT 4

#ifndef CONFIG_ARCH_SCMA11
/*! @brief Port to which the media card detect switch is attached. */
#define USR_BLK_DEV_DEV1_INT_GPIO 11 

/*! @brief Returns non zero if the media card is attached. */
# define USR_BLK_DEV_IS_DEV1_ATTACHED ((GPLR(USR_BLK_DEV_DEV1_INT_GPIO) & GPIO_bit(USR_BLK_DEV_DEV1_INT_GPIO)) != 0)
#endif

/*! @brief The name of the /proc entry as it will appear in the directory /proc. */
#define USR_BLK_DEV_PROC_ENTRY_STR  "usr_blk_dev"

/*! @brief The number of characters in USR_BLK_DEV_PROC_ENTRY_STR. */
#define USR_BLK_DEV_PROC_ENTRY_LEN  11
/*!
 * @brief The number of times the proc entry for a device can be opened.
 *
 * The number of times the proc entry for a device can be opened.  This is set
 * to one since only one user driver is needed to drive a device and if more
 * than one user process opens the entry, bad things would happen.
 */
#define USR_BLK_DEV_MAX_PROC_OPENS 1

/*! @brief Name of the user block device. */
#define USR_BLK_DEV_DEVICE_NAME_STR "usr_blk_dev"

/*! @brief Support 8 partitions per card. */
#define USR_BLK_DEV_SHIFT   3

/* @brief The maximum number of sectors which can be included in a single request. */
#define USR_BLK_DEV_MAX_SECTORS_PER_REQ 128

/*! @brief Used to enable debugging messages to be sent out the system log. */
/* #define USR_BLK_DEV_DEBUG */

/*! @brief Macro used to send debug messages to the system log. */
#ifdef USR_BLK_DEV_DEBUG
# define tracemsg(fmt,args...)  printk(__FILE__": %s: "fmt,__func__,##args)
#else
# define tracemsg(fmt,args...)
#endif

/*!
 * @brief Macro to extract the device number from the device node.
 * 
 * Each device has 8 minor numbers since* USR_BLK_DEV_SHIFT is currently 3.
 * This results in the device number being stored in upper bits.
 */
#define USR_BLK_DEV_DEVICE_NR(i_rdev) (MINOR(i_rdev)>>USR_BLK_DEV_SHIFT)

/*! 
 * @brief Timer used to debounce the insertion of a card.
 *
 * Only one timer is used for all of the devices.
 */
static struct timer_list usr_blk_dev_timer;

/*!
 * @brief The possible states of the media detection state machine.
 *
 * A list of the possible states of the card detection state machine which is
 * implemented in usr_blk_dev_poll_card_attach().
 *
 * @note Removal is not debounced since a media card may have its power removed
 * at the point at which it is detected as removed only once.  In this case the
 * safest thing to do is to reinitialize the card.
 */
typedef enum
{
    /*! @brief The media is currently not connected. */
    USR_BLK_DEV_DEBOUNCE_STATE_REMOVED,
    /*!
     * @brief The media card has been detected as inserted and is being debounced.
     *
     * The media card has been detected as inserted at least once.  The number of
     * states determines the number of times the card must be detected as inserted
     * before it will be reported as such.
     */
    /* @{ */
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTING,
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTING1,
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTING2,
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTING3,
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTING4,
    /* @} */
    /*!
     * @brief The card has been debounced as inserted, the driver must be informed.
     *
     * Once the card is detected as inserted the rest of the driver must be informed.
     * However, this may take several iterations if the thread still has not received
     * the previous state change.  This state will wait until the thread is ready to
     * receive the indication before sending it.
     */
    USR_BLK_DEV_DEBOUNCE_STATE_UPDATE_INSERT,
    /* @brief The media is currently inserted. */
    USR_BLK_DEV_DEBOUNCE_STATE_INSERTED,
    /* Removal is not debounced, so no REMOVING state exists. */
    /*!
     * @brief The card has been debounced as removed, the driver must be informed.
     *
     * Once the card is detected as removed the rest of the driver must be informed.
     * However, this may take several iterations if the thread still has not received
     * the previous state change.  This state will wait until the thread is ready to
     * receive the indication before sending it.
     */
    USR_BLK_DEV_DEBOUNCE_STATE_UPDATE_REMOVAL
} USR_BLK_DEV_DEBOUNCE_STATE_T;

/*!
 * @brief The possible sources of commands for the kernel thread to send.
 *
 * There are three different sources of a command from the kernel:
 *   - The detect interrupt,
 *   - The request queue,
 *   - A user process calling open, close, read, write etc.
 */
typedef enum
{
    USR_BLK_DEV_CMD_SRC_IRQ,  /*!< The command came from the detect interrupt. */
    USR_BLK_DEV_CMD_SRC_REQ,  /*!< The command came from the request queue. */
    USR_BLK_DEV_CMD_SRC_GEN,  /*!< The command came from a general source which can block. */
    USR_BLK_DEV_CMD_SRC__END
} USR_BLK_DEV_CMD_SRC_T;

/*!
 * @brief The state of the command being processed.
 *
 * A typical command will have the following states.  If the command originated
 * in an interrupt or from the request queue, it will not progress though the
 * final states, since there is no need to respond to the calling layer.  Please
 * note there is a difference between a command which came from the kernel
 * request queue and once which is being handled by the RW code from within the
 * thread.  The thread based read write commands progress through all of the
 * states.
 */
typedef enum
{
    /*! No command is active. */ 
    USR_BLK_DEV_CMD_STATE_NONE
    /*! A command request has been made by one of the three sources. */,
    USR_BLK_DEV_CMD_STATE_NEW,
    /*! The thread has received the command and has begun to act upon it. */
    USR_BLK_DEV_CMD_STATE_THREAD,
    /*! The thread is waiting for the user space driver to read the command. */
    USR_BLK_DEV_CMD_STATE_USR_READ,
    /*!
     * The command has been read by the user space process and the kernel thread
     * is waiting on the response.
     */
    USR_BLK_DEV_CMD_STATE_USR_WAIT,
    /*!
     * The user space process has acted upon the command and written a response
     * to the /proc entry.
     */
    USR_BLK_DEV_CMD_STATE_USR_DONE,
     /*!
      * The thread has completed operating on the command, and passed the data
      * back to the originator of the command.
      */
    USR_BLK_DEV_CMD_STATE_THREAD_DONE
} USR_BLK_DEV_CMD_STATE_T;

/*!
 * @brief Structure which holds information on the devices attached.
 *
 * The following is used as an array indexed by the device number to store any
 * data needed by the driver.  Please see the individual entries for details on
 * what is stored.
 */
typedef struct
{
    /*!
     * @brief The current state of debouncing for the device.
     * 
     * A simple state machine is used for debouncing the insertion and removal
     * of the card.  This is the state counter for that machine.  It can also
     * be used to determine the status of the card at any time while running.
     */
    USR_BLK_DEV_DEBOUNCE_STATE_T debounce_state;
    /*!
     * @brief Used to track the connection state of the media.