From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751477AbdKVHkr (ORCPT ); Wed, 22 Nov 2017 02:40:47 -0500 Received: from mga14.intel.com ([192.55.52.115]:26544 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbdKVHkp (ORCPT ); Wed, 22 Nov 2017 02:40:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="scan'208";a="4555248" Subject: Re: [PATCH V14 07/24] mmc: block: Use data timeout in card_busy_detect() To: Ulf Hansson Cc: linux-mmc , linux-block , linux-kernel , Bough Chen , Alex Lemberg , Mateusz Nowak , Yuliy Izrailov , Jaehoon Chung , Dong Aisheng , Das Asutosh , Zhangfei Gao , Sahitya Tummala , Harjani Ritesh , Venu Byravarasu , Linus Walleij , Shawn Lin , Bartlomiej Zolnierkiewicz , Christoph Hellwig References: <1511271770-3444-1-git-send-email-adrian.hunter@intel.com> <1511271770-3444-8-git-send-email-adrian.hunter@intel.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Wed, 22 Nov 2017 09:40:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/11/17 17:39, Ulf Hansson wrote: > On 21 November 2017 at 14:42, Adrian Hunter wrote: >> card_busy_detect() has a 10 minute timeout. However the correct timeout is >> the data timeout. Change card_busy_detect() to use the data timeout. > > Unfortunate I don't think there is "correct" timeout for this case. > > The data->timeout_ns is to indicate for the host to how long the > maximum time it's allowed to take between blocks that are written to > the data lines. > > I haven't found a definition of the busy timeout, after the data write > has completed. The spec only mentions that the device moves to > programming state and pulls DAT0 to indicate busy. To me it reads more like the timeout is for each block, including the last i.e. the same timeout for "busy". Note the card is also busy between blocks. Equally it is the timeout we give the host controller. So either the host controller does not have a timeout for "busy" - which begs the question why it has a timeout at all - or it invents its own "busy" timeout - which begs the question why it isn't in the spec. > > Sure, 10 min seems crazy, perhaps something along the lines of 10-20 s > is more reasonable. What do you think? We give SD cards a generous 3 seconds for writes. SDHCI has long had a 10 second software timer for the whole request, which strongly suggests that requests have always completed within 10 seconds. So that puts the range of an arbitrary timeout 3-10 s.