From patchwork Wed Sep 10 07:23:24 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kuninori Morimoto X-Patchwork-Id: 4874871 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B22209F32E for ; Wed, 10 Sep 2014 07:23:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 83BD6201C7 for ; Wed, 10 Sep 2014 07:23:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A4B2201BF for ; Wed, 10 Sep 2014 07:23:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752013AbaIJHX1 (ORCPT ); Wed, 10 Sep 2014 03:23:27 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:51791 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbaIJHXZ (ORCPT ); Wed, 10 Sep 2014 03:23:25 -0400 Received: by mail-pa0-f50.google.com with SMTP id bj1so5217715pad.9 for ; Wed, 10 Sep 2014 00:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:from:to:cc:in-reply-to:references:subject :user-agent:mime-version:content-type; bh=ozlC8/NO+FZZ70EfH/xhqQSj8gOSAM14PCoYcdLxdLo=; b=ujF5QTKncWjnuqf5uIeCKkJXXYlTY7E+e1sPUuwEKiFB55xUnyQXRQkxVV8TTOEJJY sBVNPDOfdf9NUdS/P0ii0GQnQgn9CAnsGxqsoXnRzqS9O77QnX1xWMdbARt6XLQ4H89p gcrF6MzKnG6HD8dLk0v4KWvCH7uxJqUbun/e38NIjzYK8kJXVem2CHBRiVsaHkzRxqs8 FFEnOwXgbjJ4sRHk9DFmSS+5i4Dx6ga4fq62dvANvFa4xPElqubta8PKB9UhqTDOegVC Kz9kN199SDd2c+IxQEuMlWk5WedOVVvofcGQp0BWOOXj8FlHp8tRPyZZ6njqNfJhjht+ 4zZQ== X-Received: by 10.68.215.106 with SMTP id oh10mr35831788pbc.98.1410333804703; Wed, 10 Sep 2014 00:23:24 -0700 (PDT) Received: from remon.gmail.com (49.14.32.202.bf.2iij.net. [202.32.14.49]) by mx.google.com with ESMTPSA id aa4sm14380143pad.0.2014.09.10.00.23.22 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 10 Sep 2014 00:23:24 -0700 (PDT) Date: Wed, 10 Sep 2014 00:23:24 -0700 (PDT) Message-ID: <87sik0x7kn.wl%kuninori.morimoto.gx@gmail.com> From: Kuninori Morimoto To: Ulf Hansson Cc: Geert Uytterhoeven , Chris Ball , Simon , Kuninori Morimoto , Linux-SH , linux-mmc , Shinobu Uehara In-Reply-To: References: <8761gwz2jb.wl%kuninori.morimoto.gx@gmail.com> Subject: [PATCH v3] mmc: tmio: enable odd number size access User-Agent: Wanderlust/2.14.0 Emacs/23.3 Mule/6.0 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Kuninori Morimoto Current tmio is using sd_ctrl_read16/write16_rep() for data transfer. It works if transfer size was even number, but, last 1 byte will be ignored if transfer size was odd number. This patch adds new tmio_mmc_transfer_data() and solve this issue. Tested-by: Shinobu Uehara Signed-off-by: Kuninori Morimoto --- v2 -> v3 - remove cast - remove extra variable drivers/mmc/host/tmio_mmc_pio.c | 39 +++++++++++++++++++++++++++++++++++---- 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index ff5ff0f..692e578 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -376,6 +376,40 @@ static int tmio_mmc_start_command(struct tmio_mmc_host *host, struct mmc_command return 0; } +static void tmio_mmc_transfer_data(struct tmio_mmc_host *host, + unsigned short *buf, + unsigned int count) +{ + int is_read = host->data->flags & MMC_DATA_READ; + u8 *buf8; + + /* + * Transfer the data + */ + if (is_read) + sd_ctrl_read16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1); + else + sd_ctrl_write16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1); + + /* if count was even number */ + if (!(count & 0x1)) + return; + + /* if count was odd number */ + buf8 = (u8 *)(buf + (count >> 1)); + + /* + * FIXME + * + * driver and this function are assuming that + * it is used as little endian + */ + if (is_read) + *buf8 = sd_ctrl_read16(host, CTL_SD_DATA_PORT) & 0xff; + else + sd_ctrl_write16(host, CTL_SD_DATA_PORT, *buf8); +} + /* * This chip always returns (at least?) as much data as you ask for. * I'm unsure what happens if you ask for less than a block. This should be @@ -408,10 +442,7 @@ static void tmio_mmc_pio_irq(struct tmio_mmc_host *host) count, host->sg_off, data->flags); /* Transfer the data */ - if (data->flags & MMC_DATA_READ) - sd_ctrl_read16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1); - else - sd_ctrl_write16_rep(host, CTL_SD_DATA_PORT, buf, count >> 1); + tmio_mmc_transfer_data(host, buf, count); host->sg_off += count;