From: Wolfram Sang <w.sang@pengutronix.de>
To: Philip Rakity <prakity@marvell.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
Jae hoon Chung <jh80.chung@gmail.com>,
Chuanxiao Dong <chuanxiao.dong@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sdhci: always use max timeout for xfers
Date: Fri, 25 Feb 2011 19:02:48 +0100 [thread overview]
Message-ID: <20110225180248.GA15491@pengutronix.de> (raw)
In-Reply-To: <D8739074-546D-4531-A8E9-23E9F7A33EB5@marvell.com>
[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]
Hi Philip,
On Fri, Feb 25, 2011 at 09:54:35AM -0800, Philip Rakity wrote:
> Rather then special case busy etc .. lets just use the max value.
OK.
>
> Did not remove BROKEN_TIMEOUT QUIRK so existing code will compile
> we can remove this once existing platform drivers delete usage and get
> quirk back.
If we wait for that, we'll probably wait till eternity ;) I'd vote that
removing the quirk should be part of the patch.
>
> Patch starts after ====
> =====
The usual nomenclature is that such comments simply go between '---' and the
diffstat. Most tools are prepared for this...
> The card/host controller may sometimes return a value that is
> too low and cause the h/w to timeout a transfer that would have
> worked. Using the maximum value avoids this.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
... to handle them here.
> drivers/mmc/host/sdhci.c | 48 ++++-----------------------------------------
> 1 files changed, 5 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 655617c..dd99da8 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -592,53 +592,15 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
> data->sg_len, direction);
> }
>
> -static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data)
> +static inline u8 sdhci_calc_timeout(void)
> {
> - u8 count;
> - unsigned target_timeout, current_timeout;
> -
> /*
> - * If the host controller provides us with an incorrect timeout
> - * value, just skip the check and use 0xE. The hardware may take
> + * The host controller/card can provide us with an incorrect timeout
> + * value, just use the maximum value 0xE. The hardware may take
> * longer to time out, but that's much better than having a too-short
> * timeout value.
> */
> - if (host->quirks & SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
> - return 0xE;
> -
> - /* timeout in us */
> - target_timeout = data->timeout_ns / 1000 +
> - data->timeout_clks / host->clock;
> -
> - if (host->quirks & SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
> - host->timeout_clk = host->clock / 1000;
This quirk could go then as well?
> -
> - /*
> - * Figure out needed cycles.
> - * We do this in steps in order to fit inside a 32 bit int.
> - * The first step is the minimum timeout, which will have a
> - * minimum resolution of 6 bits:
> - * (1) 2^13*1000 > 2^22,
> - * (2) host->timeout_clk < 2^16
> - * =>
> - * (1) / (2) > 2^6
> - */
> - count = 0;
> - current_timeout = (1 << 13) * 1000 / host->timeout_clk;
> - while (current_timeout < target_timeout) {
> - count++;
> - current_timeout <<= 1;
> - if (count >= 0xF)
> - break;
> - }
> -
> - if (count >= 0xF) {
> - printk(KERN_WARNING "%s: Too large timeout requested!\n",
> - mmc_hostname(host->mmc));
> - count = 0xE;
> - }
> -
> - return count;
> + return 0xE;
Why don't you remove the function entirely?
> }
>
> static void sdhci_set_transfer_irqs(struct sdhci_host *host)
> @@ -671,7 +633,7 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
> host->data = data;
> host->data_early = 0;
>
> - count = sdhci_calc_timeout(host, data);
> + count = sdhci_calc_timeout();
> sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
>
> if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA))
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2011-02-25 18:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 17:54 [PATCH] sdhci: always use max timeout for xfers Philip Rakity
2011-02-25 18:02 ` Wolfram Sang [this message]
2011-02-25 18:12 ` Philip Rakity
2011-02-25 18:22 ` Wolfram Sang
2011-02-25 18:49 ` [PATCH V2] " Philip Rakity
2011-02-25 20:07 ` Wolfram Sang
2011-02-28 2:36 ` Jaehoon Chung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110225180248.GA15491@pengutronix.de \
--to=w.sang@pengutronix.de \
--cc=chuanxiao.dong@intel.com \
--cc=jh80.chung@gmail.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=prakity@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox