From patchwork Wed Apr 4 12:48:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrian Hunter X-Patchwork-Id: 10322575 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 29FD360541 for ; Wed, 4 Apr 2018 12:54:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 132CB28E85 for ; Wed, 4 Apr 2018 12:54:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0795128E88; Wed, 4 Apr 2018 12:54:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id CC0EA28E87 for ; Wed, 4 Apr 2018 12:54:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=G8PzEeMYCsA7FdbghYHCrNgKJJWb1WolLwHW3fhzbX4=; b=kff2Sy/57OlJnu1UdztFu4LZu WMjKUvaCKHzUiMg8KViaXGQwbULv6zM/E38zsY2Zp6a+QpJCNrkWMJFEuvt+rgqlBhf3GP0XAfe9D 6fxpgdRtqrKVICyVopSmXZ0pSxDRHvDQAu4n/whWr+e8q/DZ/YnQwRFlNnqRZzjE3GF4oL0PVRhZY TRnXa4ZkUiBzRFzyUn5drxlog7ykY0m9Su5NdwO1Ae2sSxiQy0diADxjSlOBfsYsHJRPm8ZW2Ooix Roxr6Rv4SC48dAeeMhtRI8K+ndBnxjUT6omGfMj3xLqvIMeI907MWg+QXJDKQBvldi9EHxXVgPZrV /c1mvxlCQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1f3hvJ-0002gx-3V; Wed, 04 Apr 2018 12:53:57 +0000 Received: from merlin.infradead.org ([2001:8b0:10b:1231::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f3hr6-00078S-DR for linux-arm-kernel@bombadil.infradead.org; Wed, 04 Apr 2018 12:49:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g0BI1aBjHCD1dowBtG2hwOgVDe62d1I98g8Dg/C1rKo=; b=yNA5WZOE8g60Vy+BtVdWJCiFM Lx0g0r99AZZi+iFvApOGbUVDKxD9R4wXoEGHetC+4XbpxFygnsTjZvwSfNUH+lkPU8AHVCAcBmxYs Ks/xaxFBLOmbKOEPuKplCKZe5S4yAU3eYYPevlCs5/Iuf5bALzTjuRsdDjKSMueHlkED2dkO3VEbD SSTLtPH5A/TSnbiNfm2GQp7kZu60ay84Gdz2BE1CvQGTpSFGkJ86JvfAGGeacH5Gcdr8zWifx80HM 7eVvvfDXiGnXbLEF14zMrrKignQ+i5Qmd+s4XFCZJ6j7hp0X7QHYzXJNMW1Sct6428V5poQYFBcnX f/2sxLQhw==; Received: from mga05.intel.com ([192.55.52.43]) by merlin.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f3hqz-0003ZI-Jy for linux-arm-kernel@lists.infradead.org; Wed, 04 Apr 2018 12:49:34 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 05:49:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.48,406,1517904000"; d="scan'208,223"; a="39302441" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.168]) ([10.237.72.168]) by FMSMGA003.fm.intel.com with ESMTP; 04 Apr 2018 05:49:10 -0700 Subject: Re: [PATCH v3 07/11] mmc: sdhci: Program a relatively accurate SW timeout value To: Kishon Vijay Abraham I , Ulf Hansson , Tony Lindgren References: <20180307132020.30951-1-kishon@ti.com> <20180307132020.30951-8-kishon@ti.com> <1e87e5f9-13e1-765b-f077-26a55359b2c3@intel.com> <47752066-aeda-87bc-6928-1a9b80f1c45c@ti.com> <49210daa-b593-4b34-abf5-be81580723bc@intel.com> <29f640ac-b155-41c6-cf3f-8c66e1b300f1@ti.com> <1905d25f-d16d-50b1-54b0-35807d801a12@intel.com> <27e92e28-08b4-42b1-e4ef-32fa8ac785dc@ti.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <5453e71c-7dde-b305-5e0c-900bf4efe818@intel.com> Date: Wed, 4 Apr 2018 15:48:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <27e92e28-08b4-42b1-e4ef-32fa8ac785dc@ti.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180404_084929_909771_E3C64D13 X-CRM114-Status: GOOD ( 41.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, linux-mmc@vger.kernel.org, Russell King , linux-kernel@vger.kernel.org, Rob Herring , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 20/03/18 11:48, Kishon Vijay Abraham I wrote: > Hi Adrian, > > On Monday 19 March 2018 03:49 PM, Kishon Vijay Abraham I wrote: >> Hi Adrian, >> >> On Monday 19 March 2018 03:30 PM, Adrian Hunter wrote: >>> On 19/03/18 11:20, Kishon Vijay Abraham I wrote: >>>> Hi Adrian, >>>> >>>> On Friday 16 March 2018 07:51 PM, Adrian Hunter wrote: >>>>> On 16/03/18 08:29, Kishon Vijay Abraham I wrote: >>>>>> Hi, >>>>>> >>>>>> On Thursday 15 March 2018 06:43 PM, Adrian Hunter wrote: >>>>>>> On 07/03/18 15:20, Kishon Vijay Abraham I wrote: >>>>>>>> sdhci has a 10 second timeout to catch devices that stop responding. >>>>>>>> Instead of programming 10 second arbitrary value, calculate the total time >>>>>>>> it would take for the entire transfer to happen and program the timeout >>>>>>>> value accordingly. >>>>>>>> >>>>>>>> Signed-off-by: Kishon Vijay Abraham I >>>>>>>> --- >>>>>>>> drivers/mmc/host/sdhci.c | 47 ++++++++++++++++++++++++++++++++++++++++------- >>>>>>>> drivers/mmc/host/sdhci.h | 10 ++++++++++ >>>>>>>> 2 files changed, 50 insertions(+), 7 deletions(-) >>>>>>>> >>>>>>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c >>>>>>>> index 1dd117cbeb6e..baab67bfa39b 100644 >>>>>>>> --- a/drivers/mmc/host/sdhci.c >>>>>>>> +++ b/drivers/mmc/host/sdhci.c >>>>>>>> @@ -709,6 +709,36 @@ static u32 sdhci_sdma_address(struct sdhci_host *host) >>>>>>>> return sg_dma_address(host->data->sg); >>>>>>>> } >>>>>>>> >>>>>>>> +static void sdhci_calc_sw_timeout(struct sdhci_host *host, >>>>>>>> + struct mmc_command *cmd, >>>>>>>> + unsigned int target_timeout) >>>>>>>> +{ >>>>>>>> + struct mmc_data *data = cmd->data; >>>>>>>> + struct mmc_host *mmc = host->mmc; >>>>>>>> + u64 transfer_time; >>>>>>>> + struct mmc_ios *ios = &mmc->ios; >>>>>>>> + unsigned char bus_width = 1 << ios->bus_width; >>>>>>>> + unsigned int blksz; >>>>>>>> + unsigned int freq; >>>>>>>> + >>>>>>>> + if (data) { >>>>>>>> + blksz = data->blksz; >>>>>>>> + freq = host->mmc->actual_clock ? : host->clock; >>>>>>>> + transfer_time = (u64)blksz * NSEC_PER_SEC * (8 / bus_width); >>>>>>>> + do_div(transfer_time, freq); >>>>>>>> + /* multiply by '2' to account for any unknowns */ >>>>>>>> + transfer_time = transfer_time * 2; >>>>>>>> + /* calculate timeout for the entire data */ >>>>>>>> + host->data_timeout = (data->blocks * ((target_timeout * >>>>>>>> + NSEC_PER_USEC) + >>>>>>>> + transfer_time)); >>>>>>> >>>>>>> (target_timeout * NSEC_PER_USEC) might be 32-bit and therefore overflow >>>>>>> for timeouts greater than about 4 seconds. >>>>>>> >>>>>>>> + } else { >>>>>>>> + host->data_timeout = (u64)target_timeout * NSEC_PER_USEC; >>>>>>>> + } >>>>>>>> + >>>>>>>> + host->data_timeout += MMC_CMD_TRANSFER_TIME; >>>>>>> >>>>>>> Need to allow for target_timeout == 0 so: >>>>>>> >>>>>>> if (host->data_timeout) >>>>>>> host->data_timeout += MMC_CMD_TRANSFER_TIME; >>>>>>> >>>>>>>> +} >>>>>>>> + >>>>>>>> static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd) >>>>>>>> { >>>>>>>> u8 count; >>>>>>>> @@ -766,6 +796,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd) >>>>>>>> if (count >= 0xF) >>>>>>>> break; >>>>>>>> } >>>>>>>> + sdhci_calc_sw_timeout(host, cmd, target_timeout); >>>>>>> >>>>>>> If you make the changes I suggest for patch 6, then this would >>>>>>> move sdhci_calc_sw_timeout() into sdhci_set_timeout(). >>>>>>> >>>>>>> I suggest you factor out the target_timeout calculation e.g. >>>>>>> >>>>>>> static unsigned int sdhci_target_timeout(struct sdhci_host *host, >>>>>>> struct mmc_command *cmd, >>>>>>> struct mmc_data *data) >>>>>>> { >>>>>>> unsigned int target_timeout; >>>>>>> >>>>>>> /* timeout in us */ >>>>>>> if (!data) >>>>>>> target_timeout = cmd->busy_timeout * 1000; >>>>>>> else { >>>>>>> target_timeout = DIV_ROUND_UP(data->timeout_ns, 1000); >>>>>>> if (host->clock && data->timeout_clks) { >>>>>>> unsigned long long val; >>>>>>> >>>>>>> /* >>>>>>> * data->timeout_clks is in units of clock cycles. >>>>>>> * host->clock is in Hz. target_timeout is in us. >>>>>>> * Hence, us = 1000000 * cycles / Hz. Round up. >>>>>>> */ >>>>>>> val = 1000000ULL * data->timeout_clks; >>>>>>> if (do_div(val, host->clock)) >>>>>>> target_timeout++; >>>>>>> target_timeout += val; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> return target_timeout; >>>>>>> } >>>>>>> >>>>>>> And call it from sdhci_calc_sw_timeout() >>>>>>> >>>>>>>> >>>>>>>> return count; >>>>>>>> } >>>>>>>> @@ -1175,13 +1206,6 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd) >>>>>>>> mdelay(1); >>>>>>>> } >>>>>>>> >>>>>>>> - timeout = jiffies; >>>>>>>> - if (!cmd->data && cmd->busy_timeout > 9000) >>>>>>>> - timeout += DIV_ROUND_UP(cmd->busy_timeout, 1000) * HZ + HZ; >>>>>>>> - else >>>>>>>> - timeout += 10 * HZ; >>>>>>>> - sdhci_mod_timer(host, cmd->mrq, timeout); >>>>>>>> - >>>>>>>> host->cmd = cmd; >>>>>>>> if (sdhci_data_line_cmd(cmd)) { >>>>>>>> WARN_ON(host->data_cmd); >>>>>>>> @@ -1221,6 +1245,15 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd) >>>>>>>> cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200) >>>>>>>> flags |= SDHCI_CMD_DATA; >>>>>>>> >>>>>>>> + timeout = jiffies; >>>>>>>> + if (host->data_timeout > 0) { >>>>>>> >>>>>>> This can be just: >>>>>>> >>>>>>> if (host->data_timeout) { >>>>>>> >>>>>>>> + timeout += nsecs_to_jiffies(host->data_timeout); >>>>>>>> + host->data_timeout = 0; >>>>>>> >>>>>>> It would be better to initialize host->data_timeout = 0 at the top of >>>>>>> sdhci_prepare_data(). >>>>>>> >>>>>>> Also still need: >>>>>>> >>>>>>> else if (!cmd->data && cmd->busy_timeout > 9000) { >>>>>>> timeout += DIV_ROUND_UP(cmd->busy_timeout, 1000) * HZ + HZ; >>>>>> >>>>>> sdhci_calc_sw_timeout should have calculated the timeout for this case too no? >>>>> >>>>> Yes, but I was thinking you would only calculate when it was needed. >>>> >>>> I feel since we would have anyways calculated data_timeout, we should use that >>>> instead unless you see a problem with that. >>> >>> I would prefer not to calculate data_timeout when a hardware timeout is >>> being used. >>> >> >> That differs from what I had thought. This patch tries to program a relatively >> accurate SW timeout value (for data_timer) irrespective of whether hardware >> timeout is used or not. This only tries to change the 10 Sec SW timeout value >> programmed for all data transfer commands. > > IMHO since we calculate the worst case timeout value we should be using that > for all cases where we are able to calculate the timeout value so that we don't > give a too high or too low timeout value. Let me know If this sounds okay to you. I don't want to do the calculation for drivers that don't need it. How about the 3 patches attached From 0976d161bfb9c9a35c5176c8059c4ed9a985a0b2 Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Wed, 7 Mar 2018 18:50:16 +0530 Subject: [PATCH 3/3] mmc: sdhci: Program a relatively accurate SW timeout value sdhci has a 10 second timeout to catch devices that stop responding. In the case of quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, instead of programming 10 second arbitrary value, calculate the total time it would take for the entire transfer to happen and program the timeout value accordingly. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Adrian Hunter --- drivers/mmc/host/sdhci.c | 36 ++++++++++++++++++++++++++++++++++++ drivers/mmc/host/sdhci.h | 10 ++++++++++ 2 files changed, 46 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7c0683b8baba..d67ac1bf7caa 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -738,6 +738,39 @@ static unsigned int sdhci_target_timeout(struct sdhci_host *host, return target_timeout; } +static void sdhci_calc_sw_timeout(struct sdhci_host *host, + struct mmc_command *cmd) +{ + struct mmc_data *data = cmd->data; + struct mmc_host *mmc = host->mmc; + struct mmc_ios *ios = &mmc->ios; + unsigned char bus_width = 1 << ios->bus_width; + unsigned int blksz; + unsigned int freq; + u64 target_timeout; + u64 transfer_time; + + target_timeout = sdhci_target_timeout(host, cmd, data); + target_timeout *= NSEC_PER_USEC; + + if (data) { + blksz = data->blksz; + freq = host->mmc->actual_clock ? : host->clock; + transfer_time = (u64)blksz * NSEC_PER_SEC * (8 / bus_width); + do_div(transfer_time, freq); + /* multiply by '2' to account for any unknowns */ + transfer_time = transfer_time * 2; + /* calculate timeout for the entire data */ + host->data_timeout = data->blocks * target_timeout + + transfer_time; + } else { + host->data_timeout = target_timeout; + } + + if (host->data_timeout) + host->data_timeout += MMC_CMD_TRANSFER_TIME; +} + static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd, bool *too_big) { @@ -831,6 +864,7 @@ static void sdhci_set_timeout(struct sdhci_host *host, struct mmc_command *cmd) if (too_big && host->quirks2 & SDHCI_QUIRK2_DISABLE_HW_TIMEOUT) { + sdhci_calc_sw_timeout(host, cmd); sdhci_set_data_timeout_irq(host, false); } else if (!(host->ier & SDHCI_INT_DATA_TIMEOUT)) { sdhci_set_data_timeout_irq(host, true); @@ -845,6 +879,8 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd) u8 ctrl; struct mmc_data *data = cmd->data; + host->data_timeout = 0; + if (sdhci_data_line_cmd(cmd)) sdhci_set_timeout(host, cmd); diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index f6555c0f4ad3..23966f887da6 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -332,6 +332,14 @@ struct sdhci_adma2_64_desc { /* Allow for a a command request and a data request at the same time */ #define SDHCI_MAX_MRQS 2 +/* + * 48bit command and 136 bit response in 100KHz clock could take upto 2.48ms. + * However since the start time of the command, the time between + * command and response, and the time between response and start of data is + * not known, set the command transfer time to 10ms. + */ +#define MMC_CMD_TRANSFER_TIME (10 * NSEC_PER_MSEC) /* max 10 ms */ + enum sdhci_cookie { COOKIE_UNMAPPED, COOKIE_PRE_MAPPED, /* mapped by sdhci_pre_req() */ @@ -555,6 +563,8 @@ struct sdhci_host { /* Host SDMA buffer boundary. */ u32 sdma_boundary; + u64 data_timeout; + unsigned long private[0] ____cacheline_aligned; }; -- 1.9.1