From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 607E2C18DF5 for ; Tue, 20 Nov 2018 14:00:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B4A9206BB for ; Tue, 20 Nov 2018 14:00:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9B4A9206BB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728992AbeKUA3f convert rfc822-to-8bit (ORCPT ); Tue, 20 Nov 2018 19:29:35 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:44004 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725846AbeKUA3f (ORCPT ); Tue, 20 Nov 2018 19:29:35 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: sjoerd) with ESMTPSA id 1EEF427284D Received: by beast.luon.net (Postfix, from userid 1000) id 413EE3E238F; Tue, 20 Nov 2018 15:00:13 +0100 (CET) Message-ID: <515b72f2bd526d144fdc662126aa6e1e8484a25c.camel@collabora.co.uk> Subject: Re: [PATCH] mmc: core: Remove timeout when enabling cache From: Sjoerd Simons To: Ulf Hansson Cc: Wolfram Sang , Faiz Abbas , "linux-mmc@vger.kernel.org" , kernel@collabora.com, Linux Kernel Mailing List , Hongjie Fang , Bastian Stender , Kyle Roeschley , Wolfram Sang , Shawn Lin , Harish Jenny K N , Simon Horman , Hal Emmerich Date: Tue, 20 Nov 2018 15:00:13 +0100 In-Reply-To: References: <20181106133007.12318-1-sjoerd.simons@collabora.co.uk> <9051c212-6e2a-bc39-3686-693e6cd87f1d@ti.com> <303b49cbb5b687d6b6a7ad4048eda459586c0806.camel@collabora.co.uk> <20181107084741.GA31092@kunai> <20181120102300.GA1056@kunai> Organization: Collabora Ltd. Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.30.1-1 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote: > + Hal Emmerich > > On 20 November 2018 at 12:38, Sjoerd Simons > wrote: > > On Tue, 2018-11-20 at 11:23 +0100, Wolfram Sang wrote: > > > > > > > > So if you know the pattern, or just happen to hit it often in e.g. > > automated testing, it does show up during development. Otherwise it > > can > > appear to "happen once in a while randomly". > > I don't quite follow. As far as I understand, the extended timeout is > needed when turning the cache on. > > The above seems more related to flushing the cache, no? Flushing have > no timeout (also reported to be an issue [1]), which happens either > at > _mmc_hw_reset() or at _mmc_suspend(). > > What is the relation here? Yes it's the kinda of behaviour you would expect on a flush indeed! I don't know what the card actaully does when turning the cache on, whether it's actually flush of something persistent when turning the cache on after a hard poweroff or doing some other validation. All i can share is what our testing seems to indicate, which is that there is a wide spread in the time the card needs *and* there seems to be strong correlation to the I/O activity before the hard power off and the time taken by "cache on". > > Unfortunately for me, it was really a case of getting reports of > > some > > boards started failing at some point which took a while to track > > back. > > Especially since it's a battery powered device (thus hard poweroffs > > are > > rather rare) and we allow the board manufactorer to select from > > various > > different eMMCs depending on price/available at build time... > > > > > Yet, if we add a quirk for that, then we should probably mention > > > it > > > in > > > an error message when we hit -ETIMEDOUT for cache on ("does your > > > card > > > need this quirk?")? It can be pretty time consuming to track this > > > down > > > otherwise, I'd think. > > > > Yes please. It would be nice if someone happens to have the right > > contacts with Micron to see if it's a known issue for their cards > > in > > general or just this one. > > > > Also would be good to have a timeout higher then 1 seconds (or for > > these cards not have one?); On our testing thusfar we've seen > > timeouts > > up to 850ms, but it's impossible to ensure that that's the true > > upper > > bound. > > Using no limit of the timeout, would mean we may hang for ~10 minutes > (MMC_OPS_TIMEOUT_MS) instead, no thanks. Probably a silly question, but would this actually cause e.g. boot to hang while waiting for the card (assuming rootfs is somewhere else)? > I am fine with let's say double of 850ms (1700ms), to have some room. > > Anyway, the point is, the timeouts in the spec is there for reason. > Unfortunate I think the spec is "lazy" in some other regards and > don't > specify timeouts, which complicates things. -- Sjoerd Simons Collabora Ltd.