From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlos Aguiar Subject: [PATCH] fix MMC response types Date: Mon, 27 Mar 2006 08:56:01 -0400 Message-ID: <4427E0E1.8050703@indt.org.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080606060104060703010707" Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-omap-open-source-bounces+gplao-linux-omap-open-source=gmane.org@linux.omap.com Errors-To: linux-omap-open-source-bounces+gplao-linux-omap-open-source=gmane.org@linux.omap.com To: balrogg@gmail.com, linux-omap-open-source@linux.omap.com List-Id: linux-omap@vger.kernel.org This is a multi-part message in MIME format. --------------080606060104060703010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, let's try again, now with the patch... Hi Andrzej and folks, Attached to this mail follow my propose of fixing MMC responde types in mmc_omap_start_command(). This is based on the patches of the thread '[RFC] mmc: add OMAP driver' that I sent to LKML mailing-list in order to have integrated the MMC OMAP driver on the mainline kernel. Comments and suggestions are welcome. BR, Carlos. -- Carlos Eduardo Software Engineer Nokia Institute of Technology - INdT Embedded Linux Laboratory - 10LE Phone: +55 92 2126-1079 Mobile: +55 92 8127-1797 E-mail: carlos.aguiar@indt.org.br --------------080606060104060703010707 Content-Type: text/x-patch; name="mmc_omap_rsp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mmc_omap_rsp.patch" Index: linux-omap-2.6.git/drivers/mmc/omap.c =================================================================== --- linux-omap-2.6.git.orig/drivers/mmc/omap.c 2006-03-27 08:29:08.000000000 -0400 +++ linux-omap-2.6.git/drivers/mmc/omap.c 2006-03-27 08:35:03.000000000 -0400 @@ -49,6 +49,7 @@ #include "omap.h" #define DRIVER_NAME "mmci-omap" +#define RSP_TYPE(x) ((x) & ~(MMC_RSP_BUSY|MMC_RSP_OPCODE)) #ifdef CONFIG_MMC_DEBUG #define DBG(x...) pr_debug(x) @@ -185,36 +186,27 @@ mmc_omap_start_command(struct mmc_omap_h host->hw_bus_mode = host->bus_mode; } - if (!(cmd->flags & MMC_RSP_PRESENT)) - resptype = 0; /* Resp 0 */ - - if (cmd->flags & MMC_RSP_136) - resptype = 2; /* Resp 2 */ - else { - if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) - resptype = 3; /* Resp 3 */ - else - resptype = 1; /* Resp 1, Resp 1b */ + /* Our hardware needs to know exact type */ + switch (RSP_TYPE(mmc_resp_type(cmd))) { + case RSP_TYPE(MMC_RSP_R1): + /* resp 1, resp 1b */ + resptype = 1; + break; + case RSP_TYPE(MMC_RSP_R2): + resptype = 2; + break; + case RSP_TYPE(MMC_RSP_R3): + resptype = 3; + break; + default: + break; } - /* Protocol layer does not provide command type, but our hardware - * needs it! - * any data transfer means adtc type (but that information is not - * in command structure, so we flagged it into host struct.) - * However, telling bc, bcr and ac apart based on response is - * not foolproof: - * CMD0 = bc = resp0 CMD15 = ac = resp0 - * CMD2 = bcr = resp2 CMD10 = ac = resp2 - * - * Resolve to best guess with some exception testing: - * resp0 -> bc, except CMD15 = ac - * rest are ac, except if opendrain - */ - if (host->data) { + if (mmc_cmd_type(cmd) == MMC_CMD_ADTC) { cmdtype = OMAP_MMC_CMDTYPE_ADTC; - } else if (resptype == 0 && cmd->opcode != 15) { + } else if (mmc_cmd_type(cmd) == MMC_CMD_BC) { cmdtype = OMAP_MMC_CMDTYPE_BC; - } else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) { + } else if (mmc_cmd_type(cmd) == MMC_CMD_BCR) { cmdtype = OMAP_MMC_CMDTYPE_BCR; } else { cmdtype = OMAP_MMC_CMDTYPE_AC; --------------080606060104060703010707 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --------------080606060104060703010707--